Recheck the entry at the current index after we remove one. This isn't
strictly necessary, since the next pass will get it anyway.
Using a vector as opposed to our own realloc()'d array means indexing
beyond the size() is undefined behavior, so it's better to be safe.
This is how it should have been handled anyway. This fixes a (benign)
race condition when the server is killed, as well as gprof builds.
Also updated tdata.
This fixes a crash due to the invalidated iterator continuing to loop.
It should be safe to assume there's only ever one duplicate/stale player.
Also updated tdata.
* Fixed Nano stamina not being halved on respawn
* Reverted the default argument to terminate() change because MSVC is
undable to disambiguate the function pointer passed to sigaction()
* Fatal errors during init (like in TableData) can just call exit(1)
directly anyway (missing "OpenFusion: terminated." be damned)
* Switched to a slightly more portable syntax for getting the version
in the Makefile
* We shouldn't join the shard thread in the signal handler because the
thread the signal handler ends up running in is undefined behaviour and
we don't strictly need to join it anyway
Many of these issues were discovered on OpenBSD.
* Gave it a default argument, since we never actually care about it, but
it needs to have it to conform to the signal handler prototype
* Constricted the area locked by activeCrit to only the block that deals
with the connections vector, to lower the chance of a future badly
placed call to terminate() deadlocking the server instead
* Extracted PollFD manipulation and nonblocking socket configuration
into helper functions
* Replaced the connections list with an unordered_map
* Dynamically grow the number of PollFD structures with realloc()
With these changes done, the server's CPU usage is completely diminished
from its old average of ~47% to ~0.07%, with occasional spikes up to ~14%.
This change required sacrificing both code cleanliness and the specific
error reports from perror(). Those could have been kept with a portable
wrapper, but that's too much work. We'll do it if unforseen errors
arise.
It was a leak in the abstraction that we weren't even using that much.
This is technically a de-optimization, but it's okay since it's not a
hot code path.
