01-23-2015, 02:30 AM
I guess there's already a zlib binding that we can use for this.
Network API
|
01-23-2015, 02:30 AM
I guess there's already a zlib binding that we can use for this.
01-24-2015, 05:08 AM
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.
01-25-2015, 12:00 AM
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.
01-25-2015, 12:09 AM
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.
01-25-2015, 12:24 AM
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.
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.
01-25-2015, 01:00 AM
The main point about my solution is it removes the multithreading element.
01-25-2015, 01:02 AM
It doesn't do so well enough, because you still have no guarantee about whether the callback will be called anymore or not.
01-25-2015, 06:04 AM
Great, now I'm getting random crashes in LibEvent code.
01-26-2015, 11:53 PM
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? |
« Next Oldest | Next Newest »
|