Anyone have an example of a GUI server using winsock without getting the GUI blocked when listening?

What's the easiest way to fix it?

thread ?

Or WSAAsyncSelect.

Basically it enables you to setup a custom message that will be passed to your window on every network event.

In case you want decent performance (either high throughput or lots of clients), you need I/O Completion ports or WSAEventSelect - and you want nonblocking sockets.

If you're only going to support a very few simultaneous connections, you can go through with threads + blocking sockets, but since you're likely to need synchronization, doing a proper EventSelect from the start is the smartest way to go.

[content deleted]

"block", not "lock". And again, smarter to do things properly and set up events.

[content deleted]

I'll try being patient with you. First of all, thread-per-socket is not a good idea, and Win32 threads are pretty lightweight - certainly more lightweight than the typical unix idea of "a process per connection". You can only have a limited number of threads though, with 4k stacks I managed to create somewhere between 1000 and 2000 threads on win32. But doing something like that is flawed, even if threads will mostly be BLOCK_WAITING.

With the event socket model, you create an array of MAXIMUM_WAIT_OBJECTS linked lists. Each list entry will have the required client state information. You add new clients to the list that currently has the fewest entries. You then associate an array of MAXIMUM_WAIT_OBJECTS event handles with your client-list. Then, after the necessary socket setup, you use a single thread to WaitForMultipleObjects on your handle array.

Once WFMO returns, you loop through the client link-list the triggered event corresponds to, handle any active sockets in the list, and finally re-issue a WFMO. You can either use this worked thread and a separate GUI thread, or you can add a timeout to WFMO and handle everything in one thread.

utorrent uses this technique to handle many clients, doesn't have trouble saturating a 100mbit link, and isn't very CPU intensive. Try doing that with a-thread-per-socket... even if you manage to use all lock-free algorithms and no synchronization primitives, I'll bet your CPU usage isn't very friendly. And complexity will be higher.

[content deleted]