Network API
#81
I guess there's already a zlib binding that we can use for this.
Reply
Thanks given by:
#82
I've run into a nasty race condition.
Say there's a network server listening, and it has active connections. Suddenly the server is stopped and deleted by the app. The connections are still alive, so it's possible that the sockets' callbacks will still be called in a second thread, while the first thread is destroying both the server and its attached links. Unfortunately LibEvent seems to provide very little to prevent this behavior - there is no way to wait for a reasonable "no event executing" state.
Reply
Thanks given by:
#83
Maybe the best way to handle the race condition is to allow a link to outlive a server? Only set the Server of the links to null.
Reply
Thanks given by:
#84
It's not so much about a link-to-server, it's about link-to-callback. There's really no way to guarantee that a LibEvent callback won't be called after a certain point. So I tried keeping the link alive until the callback reports link closed, or the local end is closed.
Reply
Thanks given by:
#85
Ah. Libevent should call all callbacks on the same thread, so as long as you are in an event callback there can't be another event executing. So what you need to do is trigger the shut-down to occur on event loop thread by using a custom event.
Reply
Thanks given by:
#86
Feel free to experiment with this, if you want. I think I'm gonna settle for the current solution now.



Also note, LibEvent also has "deferred callbacks" that may be called after all the events are collected. So your solution still might not work.
Reply
Thanks given by:
#87
The main point about my solution is it removes the multithreading element.
Reply
Thanks given by:
#88
It doesn't do so well enough, because you still have no guarantee about whether the callback will be called anymore or not.
Reply
Thanks given by:
#89
Great, now I'm getting random crashes in LibEvent code.
Reply
Thanks given by:
#90
I seem to have hunted down all of the issues, the UseLibevent branch is now working properly for me. I'd appreciate if someone else did some testing as well - compile and run the server, have it talk over webadmin (use the Debuggers plugin to stress-test the webadmin interface) while playing on it for a while, turn on auth so that an extra SSL connection is established to Mojang servers, etc.

In the meantime, what should we do about UDP? It'd be nice to support it as well. Anyone brave enough to draft an API for that?
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)