Thanks a lot for your great idea, dude. I certainly will use it very soon. :-)
I took a look at IPCs, but now, I would like something that stops receiving new clients and forces the current ones to finish their processing. Probably I may use IPCs (or any existing feature in MHD) to send some signal to the clients warning that the server will be finished in N seconds, so the clients could finish their processing immediately. On Mon, Mar 27, 2017 at 1:00 AM, Christian Grothoff <groth...@gnunet.org> wrote: > On 03/26/2017 10:36 PM, Evgeny Grin wrote: > > On 26.03.2017 8:33, silvioprog wrote: > >> I found the following related message: > >> > >> https://lists.gnu.org/archive/html/libmicrohttpd/2014-09/msg00012.html > >> > >> I've used a similar logic, but with item X below, because I need to wait > >> the client processing: > >> > >> 1) MHD_quiesce_daemon() > >> *X) while (info.num_connections > 0) sleep(0.5s) # pseudo code* > >> 2) MHD_stop_daemon() > >> 3) close() > >> > >> Real implementation: > >> > >> bool bf_httpsrv_shutdown(struct bf_httpsrv *srv, bool force) { > >> MHD_socket fd; > >> if (srv && srv->listening) { > >> fd = MHD_quiesce_daemon(srv->mhd); > >> if (!force) > >> while (MHD_get_daemon_info(srv->mhd, > MHD_DAEMON_INFO_CURRENT_CONNECTIONS)->num_connections > 0) > >> usleep(1000 * 500); //TODO: allow to use external > callback > >> MHD_stop_daemon(srv->mhd); > >> if (fd != MHD_INVALID_SOCKET) > >> close(fd); > >> srv->listening = false; > >> return true; > >> } > >> return false; > >> } > >> > >> > >> Calling it with bf_httpsrv_shutdown(srv, false) the server stops waiting > >> for clients processing. > >> > >> So, what do you think about the logic above? Should it be improved?! > >> > >> Thanks in advance for any suggestions! > > > > If you don't check returned value from MHD_quiesce_daemon(), you may > > later found that you didn't quiesced daemon, so move check right after > > MHD_quiesce_daemon() and added error handling. > > If you didn't set connection timeout, connection may live indefinitely. > > Moreover, even with connection timeout, clients may continue processing > > on same HTTP 1.1 connections with new requests indefinitely. > > Furthermore, even with HTTP 1.0 and connection timeout hypothetical > > client may read answer very slow with results in very long unpredictable > > closure of connection. > > So: yes, you code will work but may result in very long (hours, for > > example) or even indefinitely long daemon shutdown. > > > > And while Evgeny is 100% correct, let me point out the opposite concern: > 0.5 s can still be an eternity (think: shell scripts, automated tests, > etc.) and that you ideally should use MHD_OPTION_NOTIFY_CONNECTION to > notify main() that you are "done". For example by doing a semaphore-down > operation/IPC write in main() and a semaphore-up()/IPC read in the > callback IF you are past quiesce and info tells you that you are the > last connection. > > -- Silvio Clécio
