On 12/06/2015 01:49 AM, Evgeny Grin wrote: > Christian, > > You solved the problem. I was able to reproduce the problem: if you > make a single request from chrome for example and wait more than > timeout seconds, than all following requests will be put on long > waiting. But it you make a new request from another client or tab, > than all requests (including waiting ones) are served immediately. > Debugger show that MHD select thread are waiting for return from > MHD_sys_select_ when client are in long waiting. On latest SVN the > problem is gone. Do we need any refactoring/renaming in MHD code as > we are using MHD_EPOLL_TURBO in MHD_start_daemon_va to prevent > sockets shutdown on W32?
Ah, that hack explains why shutdown() wasn't done on W32, which created this issue in the first place. Btw, I don't know if the shutdown() on line 1033 that I introduced (just before close()) hurts in this respect. I just kept it as it was present in the logic I moved to run earlier. There it was #ifdef WINDOWS, so I figured it was, eh, desired. But maybe it's OK and it's just that the #ifdef WINDOWS vs. #ifdef CYGWIN vs. #ifdef MHD_WINSOCK_SOCKETS is a bit confusing... With respect to your last question, I don't think the W32-logic should abuse the EPOLL_TURBO flag like that. It would seem simpler to just #ifndef the shutdown() call in MHD_connection_close() and the set-to-nonblocking logic in daemon.c. That may even result in a smaller W32 binary (not sure the CC will understand that the flag is set unconditionally and do DCE otherwise).
signature.asc
Description: OpenPGP digital signature
