syndicate-2017/examples/ircd/TODO.md

1014 B

Try changing the motd and saving the file. It'll reload. The log messages suggest that the server is dropping extant connection - as expected - but it immediately comes back momentarily before going away properly. The session is able to reboot due to the glitching in assertion of the listen port more quickly than the latency of teardown of the previous connection; so the new session-listener responds to the assertions from the old connection before the old connection has a chance to die. Of course, it does die (since commit 11de40c), but having that zombie reborn new session is annoying.

  • This is thorny. You'd think that having a session wait for its line-reader to go would be enough, but the multiple nested during/spawns creating the sessions mean that no matter how long the old session instance sticks around, a new session will appear before we're ready! ... maybe there's no way at all to disambiguate old/new instances without, say, a unique listener-socket identifier??