'write python "pre-threaded" server client program'

It wrote something quick enough, except it was a
plain simple threaded server, not PRE-threaded.

Pre-threaded creates/manages a 'bank' of threads at
the start so they don't have to be created one at
a time on demand - quicker, it's the highest-
performing kind of server.

'write python "pre-threaded" "non-blocking" server client program'

It created a non-blocking server, but NOT threaded or pre-threaded.

Seems AI doesn't always "get it" :-)


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/31/26 03:00, c186282 wrote:

'write python "pre-threaded" server client program'

It wrote something quick enough, except it was a
plain simple threaded server, not PRE-threaded.

Pre-threaded creates/manages a 'bank' of threads at
the start so they don't have to be created one at
a time on demand - quicker, it's the highest-
performing kind of server.

'write python "pre-threaded" "non-blocking" server client program'

As a non AI, I wouldn't have known what pre-threaded meant. I would have thought what you describe was called using a thread pool. The AI may
have decided the overall performance hit of creating new threads was low
and not worth the complexity of a thread pool, or it may be the
threading library/OS is effectively doing a thread pool behind the scenes.

My naive solution would be to avoid threading, use IO with callbacks, or
use a handful of long-lived threads, like the "worker thread"/"gui
thread" pattern.

It created a non-blocking server, but NOT threaded or pre-threaded.

Seems AI doesn't always "get it"ÿ :-)

Perhaps you need to have more of a conversation with the AI.


--- PyGate Linux v1.5.10
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 1 Feb 2026 10:09:08 +0000, Pancho wrote:

My naive solution would be to avoid threading, use IO with
callbacks, or use a handful of long-lived threads, like the "worker thread"/"gui thread" pattern.

Coroutines (in the ?stackless? form) are making a bit of a comeback at
the moment. You see these ?async/await? constructs appearing in
languages like JavaScript and Python.

--- PyGate Linux v1.5.10
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2/1/26 05:09, Pancho wrote:

On 1/31/26 03:00, c186282 wrote:

'write python "pre-threaded" server client program'

It wrote something quick enough, except it was a
plain simple threaded server, not PRE-threaded.

Pre-threaded creates/manages a 'bank' of threads at
the start so they don't have to be created one at
a time on demand - quicker, it's the highest-
performing kind of server.

'write python "pre-threaded" "non-blocking" server client program'

As a non AI, I wouldn't have known what pre-threaded meant. I would have thought what you describe was called using a thread pool. The AI may
have decided the overall performance hit of creating new threads was low
and not worth the complexity of a thread pool, or it may be the
threading library/OS is effectively doing a thread pool behind the scenes.

My naive solution would be to avoid threading, use IO with callbacks, or
use a handful of long-lived threads, like the "worker thread"/"gui
thread" pattern.

It created a non-blocking server, but NOT threaded or pre-threaded.

Seems AI doesn't always "get it"ÿ :-)

Perhaps you need to have more of a conversation with the AI.

I had researched the various server types a few years
ago and created examples of each. At base there is "select",
"forked" and "threaded". There are 'pre-forked' and
'pre-threaded' variants. There is more overhead in creating
a fork than for a thread. The very highest speed/capacity
server is pre-threaded.

"Thread pool" would be an alt term for 'pre-threaded'.
You set up ten or twenty threads ahead of time and
then feed them the needed info. If you need more then
there's logic for expanding the pool.

Just for fun, ask Chat to write you a threaded server
and appropriate testing client - takes a couple of
seconds. The actual code for a threaded server is
surprisingly short. Though Chat doesn't add comments
because it doesn't *understand* anything, you won't
need comments to follow its Python threaded example.

Blocking servers can be OK for lots of little uses,
however non-blocking variants can be more generally
useful/intelligent since other useful stuff can be
going on in-between messages with the clients.

Python is not the best language for servers, but it
is more self-documenting than 'C' and thus good for
doing research/experiments. Next time I'm going to
have Chat write 'C' versions and see how those look.
Never tried to write servers in old COBOL or FORTRAN,
dunno if it can be done. You can in modern Free Pascal
however, but the code is a tad clunky.


--- PyGate Linux v1.5.10
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2/1/26 16:09, Lawrence D?Oliveiro wrote:

On Sun, 1 Feb 2026 10:09:08 +0000, Pancho wrote:

My naive solution would be to avoid threading, use IO with
callbacks, or use a handful of long-lived threads, like the "worker
thread"/"gui thread" pattern.

Coroutines (in the ?stackless? form) are making a bit of a comeback at
the moment. You see these ?async/await? constructs appearing in
languages like JavaScript and Python.

Modern need is often for the highest speed/capacity
possible, something that can deal with hundreds or
thousands of internet clients.

Never explicitly delved into co-routines, servers or
otherwise. Sounds kind of complex to manage. It's
kind of like starting several free-running pgms at
the same time that can talk to each other, almost
forking but not quite.

Now, deep in the background of Python/C/etc, the
library writers MAY be using them ...


--- PyGate Linux v1.5.10
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)