By: Tom Sydney Kerckhove <syd@cs-syd.eu>
warp: wait for accepted connections without changing what getCount counts Alternative to counting accepted connections in the counter that getCount reports. Same bug, same fix in kind, but the public counter is left alone. fork hands the new connection to settingsFork and the accept loop goes straight back to accept. The counter is raised by onOpen, which runs in the forked thread, so from accept returning until that thread is scheduled the connection exists and the counter does not count it. gracefulShutdown runs waitForZero on that counter, so a connection accepted in that gap reads as zero and warp stops while holding it. Rather than move when the existing counter is raised, this adds a second one. It is raised in fork before settingsFork, in the accept loop's own thread, and lowered in a finally around the whole thread body, so it counts every connection warp is holding from the moment accept hands it over until the thread is done with it. gracefulShutdown waits on that. waitForDecreased, the EMFILE backoff, moves to it too: a connection warp has accepted is holding a descriptor whether or not its thread has run, so this is the count that says whether there is anything to wait for. It is internal, so nothing observable changes. onOpen and onClose are untouched, so getCount and currentOpenConnections keep counting connections that have been opened, exactly as before. The cost is a second counter and one more argument through acceptConnection and fork. Whether that is better than the one-counter version depends on how much the published meaning of getCount is worth, which is yours to weigh. GracefulShutdownSpec gets the same test as the one-counter version, and it passes here too: 122 examples, 0 failures.