Ahh, this has been tried in a fashion. The main thread starts a listen-once worker. When that worker gets a request it accepts it and tells the main thread. The main thread starts a new listen-once to "catch" the next client.

If connections ever arrive rapidly you lose some of them.


If multithreading in a socket server has any advantage to a VB6 program, it is probably in keeping some worker threads to do "work." In other words use just one thread to "own" all of the sockets and manage communications, and dispatch any "heavy lifting" non-communication work like database activity, disk I/O, calculations, etc. to a worker.

This isn't so great through if your server mostly does file transfers. If one thread reads a lot of disk data and then passes it to the sockets thread to send it, you get eaten alive with the overhead of cross-thread marshalling of the data blocks.