🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Sodding IO COmpletion Ports...

posted in DruinkJournal
Published June 06, 2006
Advertisement
I've been having a lot of issues with IO completion ports for TEH MORPG!!1. I seem to remember having these exact problems the last time I tried, so there might be something I'm mis-understanding.
An example of a problem I'm having is that connect() doesn't want to work properly. I use WSAEventSelect() to get notification when the connect is complete, and I have a thread that only handles new client and connect complete notifications. However, I quite often never get the connect complete notification (the event is never signalled). This might be unrelated to the IOCP of course.

Another thing is I have all sorts of issues when a client disconnects. If the server kills the connection, then it tends to send data, then Release() the CSocket. Release() frees the socket descriptor with closesocket() and clears any buffers. That however, causes the IOCP to spaz out, since the socket was ripped out from under it. Then the write event goes through, and I have to check that the socket hasn't already been freed, which is horrible.
What I think I need is some sort of pool of "dead" sockets, and when CSocket::Release() is called, the socket is added to the pool, and the IO is cancelled (not sure how to do that though). When the IO cancel event is picked up by a worker thread, the socket can be removed from the dead pool and properly destroyed.

Whether that'll work or not is anyones guess. This code is turning into a bit of a mess, mainly because CSocket and CSocketManager are friends of each other. I might make an interface to CSocketManager that's only availiable to CSocket, that'd probably tidy things up and make syncronisation easier.

I was also reading about a lock free free list implementation in Game Programming Gems 6, on the train this morning. I really don't understand how it works, but it looks perfect for my uses. I already have 3 free lists for storing a list of overlapped structures for IOCP, sockets, and something else I forget at the moment. All of them need synchronised, since all of them are accessed from all threads. "All threads" being the main thread, the accept()/connect() thread, and the numProcessors*2 worker threads - making a total of 6 threads in my case, and that's just for the socket manager...


In other news, we got into the building 15 mins late this morning, because we only have one set of keys, and the one person with them was late this morning. We can't get another set cut because nobody can pay for them, because we don't have an office manager yet. Fun.

Anyway, back to work...
Next Entry Screw IOCP
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement