Christian Grothoff wrote: > [...] > Are you, by chance, doing significant blocking operations within the > single-threaded event loop? (Outch...). I understand that then our extra > run through select() might be, eh, "annoying", but the big issue is your > blocking behavior in a single threaded server.
Yes, I admitted as much, perhaps in too many words! Indeed there are significant blocking operations in a single-threaded event loop, which is admittedly imperfect. (You can reproduce it by changing your single-threaded demo program to sleep(4) before returning MHD_YES from the connection callback.) > Anyway, we could probably do something about this (reducing your pain, > but not solving the main problem). I'm thinking of something along the > lines of the attached patch. It MAY help, but ONLY if you're using > epoll() and TURBO mode, so you must pass both: > MHD_USE_EPOLL_LINUX_ONLY | MHD_USE_EPOLL_TURBO Thanks! I tested the patch (with the "0 ==" typo fixed to "0 !="). It helped some, confirmed both by firefox/firebug and server-side strace. What happens with the new code is that one response object does get transmitted right away. Unfortunately, that's only the 160ish bytes of HTTP response headers, and not the response body. (An amateurish loop rerunning the write_handler a few times didn't help.) - FChE
