Thread: Event-notified asynchronous Winsock methods

Ok, after several long distractions (games, other projects, vacation), I'm finally back to writing my asynchronous winsock wrapper. Originally, I had a thread waiting on the events and extracting the network notifications to a queue for later processing by main() (one call to 'execQueuedEvents()' executes preset callbacks set by the user). However, coming back with a fresh mind, it has suddenly occurred to me that I could just have a function that polls the events from main() ('while(WaitForMultipleObjects..)'). By my reasoning, this would eliminate the need for a separate thread - and therefore the thread-synchronization problems associated with it. After doing a profiling test I determined that WaitForMultipleObjects does not cause any significant delay when used for polling either; so I'm in a dilemma: Should I redesign the wrapper without the thread, or is there some advantage to using one? I currently see no reason not to get rid of it, but all the sites I've seen use a thread to handle the network events.

Does anyone have any comments or suggestions about this?

Yes, it is convenient. But window messages are slow, and (of course) require a window. I am trying to implement a wrapper using WSAEventSelect() instead of AsyncSelect() so that it can be used with any and all of my applications, running at a reasonable speed so that it can also be used for realtime multiplayer games.

**P.S.
Also, if an asynchronous call to send() completes successfully (not WSAEWOULDBLOCK), does that mean that the buffer can then be safely deleted?

Ok, well after reading more about how FD_WRITE behaves, I've decided that I'm going to try writing my own output buffer code that automatically completes send requests once the socket is writable, even if send() initially gives a wouldblock error... and it seems to me that the most efficient method would be to do so in a separate thread, even with all the thread synchronization headaches. I suppose it'll be a learning experience

I'd still like to hear any comments or suggestions from people though.

All you need are two things:

1) a good (sync) socket wrapper.
2) a good thread wrapper.

from those simple building blocks you can create powerful sync/async networking objects without even bothering with MS's nutty API.

>>1) a good (sync) socket wrapper.
I wrote a mediocre blocking socket wrapper.

>>2) a good thread wrapper.
I wrote one. No idea how good it is though.

from those simple building blocks you can create powerful sync/async networking objects without even bothering with MS's nutty API.

Are you speaking of blocking using select() inside a separate thread? If so, how do you signal that the program should close? And if you're speaking of polling using select(), isn't that really inefficient? And if neither of the above, then what are you speaking of? lol

what I did was take a (blocking) socket class I wrote and derived a class from it that maintained a linked list of thread objects. all of the blocking calls were then overridden to launch a thread that would monitor and timeout the operation. besides this I always run any networking code from it's own thread to simplify things. you may find it easier to go about it some other way - that's just how I felt like doing it at the time and it worked rather well for me.

>>all of the blocking calls were then overridden to launch a thread that would monitor and timeout the operation.
Wow, didn't that give you a huge performance slowdown? I read somewhere that if you have too many threads going on then you lose a lot of CPU cycles to context switches, and also it takes time to create a thread. That didn't give you any problems??

>> Wow, didn't that give you a huge performance slowdown?

as long as the threads are already created (in suspended mode), there isn't much of a performance penalty. when the thread completes, you start it again in suspended mode till the next operation.

>> I read somewhere that if you have too many threads going on then you lose a lot of CPU cycles to context switches

that's going to depend on two things - how many threads you have running at one time, and the priority of each thread. the implementation I used didn't require too many threads, and I kept their priority levels relatively low.

going back to your original question I'd say stick with your current method, except maybe put your WaitForMultipleObjects() routine in it's own thread so that you can use main() for other things (the user interface, for instance).

>>going back to your original question I'd say stick with your current method, except maybe put your WaitForMultipleObjects() routine in it's own thread
By 'current method' are you referring to the 'thread waiting on events and extracting notifications to a queue for later processing by main()' method, or the 'forget the thread and just use WaitForMultipleObjects with a timeout of 0 in main()'? I was sort of hoping I could do away with the thread without killing performance/functionality.