+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Network API (/thread-1700.html)
RE: Network API - xoft - 01-23-2015
I guess there's already a zlib binding that we can use for this.
RE: Network API - xoft - 01-24-2015
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.
RE: Network API - worktycho - 01-25-2015
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.
RE: Network API - xoft - 01-25-2015
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.
RE: Network API - worktycho - 01-25-2015
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.
RE: Network API - xoft - 01-25-2015
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.
RE: Network API - worktycho - 01-25-2015
The main point about my solution is it removes the multithreading element.
RE: Network API - xoft - 01-25-2015
It doesn't do so well enough, because you still have no guarantee about whether the callback will be called anymore or not.
RE: Network API - xoft - 01-25-2015
Great, now I'm getting random crashes in LibEvent code.
RE: Network API - xoft - 01-26-2015
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?