Rad! I'll try it out and get back to you. On Apr 25, 2013, at 4:16 AM, Christian Grothoff <[email protected]> wrote:
> Dear Scott, > > I don't like the limitations of your patch, and I think I've come up with a > much cleaner solution. The attached UNTESTED diff should apply cleanly > against SVN HEAD. Please let me know if it works, and I would > really appreciate a test case (or a few, for the different threading > modes), as this does seem a bit convoluted and there might be corner > cases I overlooked. And after all, the last thing you want for a > zero-downtime deployment is crashing code ;-). > > Especially with a test, I can see this going into MHD relatively quickly ;-). > > > Happy hacking! > > Christian > > On 04/25/2013 10:31 AM, Scott J. Goldman wrote: >> Hi. >> >> Where I work, we do continuous deployment of services, so it's important to >> us to be able to be able to deploy new code and restart our services in a >> way that doesn't cause downtime. One of the ways we do that is by deploying >> daemons which can fork-exec themselves and inherit the listening socket. >> With a slightly modified libmicrohttpd, we implemented this functionality. >> It works like this: >> 1. send SIGUSR1 to the daemon >> 2. daemon fork-exec's a new version of itself, passing the fd# of the >> listening socket, and a status pipe via command-line args >> 3. new daemon initializes, starts accepting connections on the socket (with >> MHD_OPTION_LISTEN_SOCKET), and sends a message via the status pipe >> 4. old daemon operates normally until it gets the status message, and then >> stops accept()ing new connections, but continues processing old ones >> 5. old daemon finishes processing all remaining clients, and terminates >> >> libmicrohttpd had nearly all the functionality we needed, except for having >> the "quiesce" functionality, to stop accept()'ing new connections, while >> continuing to process existing clients. I'm wondering if you would consider >> this feature for inclusion in your mainline version of the library. I've >> included a link to our patch below that is our rough attempt to hack in this >> functionality. I would be happy to revise it with your feedback. >> >> https://gist.github.com/scottjg/5458005 >> https://gist.github.com/scottjg/5458005/raw/4ad505101f80485e24a6a2f1092f173706749df3/quiesce-api.patch >> >> The main issue with the patch is that calling shutdown() on the listening >> socket is no longer acceptable in this mode. On Linux, calling shutdown() in >> the old daemon will prevent the new daemon from being able to accept() new >> clients. For our purposes we used the alternate pipe method to wake up the >> event loop, which appears to works fine. >> >> Cheers, >> -sjg > <quiesce.diff>
