Hi Christian, Looking at the 0.9.38 source code, I am getting confused. Setting MHD_USE_THREAD_PER_CONNECTION eventually results in creating two threads: create_thread (&daemon->pid, daemon, &MHD_select_thread, daemon) create_thread (&connection->pid, daemon, &MHD_handle_connection, connection) Entry points MHD_select_thread eventually calls select() on the listening socket. Entry points MHD_handle_connection eventually calls select() on the connection socket.
Louis Le 16/03/15, Christian Grothoff <[email protected]> a écrit : > On 03/16/2015 05:09 PM, [email protected] wrote: > > Le 11/03/15, *Christian Grothoff * <[email protected]> a écrit : > >> On 03/11/2015 12:58 PM, [email protected] wrote: > >>> Hi Christian, > >>> > >>> I wanted to use external threads because my system has the following > >>> constraints: > >>> 1) One connection per thread: the response to the client is time critical > >>> and I cannot afford that a connection delays another one. > >> > >> Then you should use the one-thread-per-connection mode, that is exactly > >> what you want. MHD will use a thread for each connection, which matches > >> your requirements. This method also has no limits on open FDs as MHD > >> doesn't use select() but blocking read/write operations instead. > > > > Are you refering to MHD_USE_THREAD_PER_CONNECTION? > > Yes. > > > Or using > > MHD_OPTION_CONNECTION_LIMIT > > No, that option has nothing to do with the threading modes. > > > set to MHD_OPTION_THREAD_POOL_SIZE? > > No, a thread pool is again different, as there you use one thread to > handle multiple connections, which may give you the delays you found so > problematic. > > > In both cases shouldn't I use MHD_USE_POLL in order not to use select ()? > > MHD_USE_POLL has no impact on MHD_USE_THREAD_PER_CONNECTION, as in that > case neither select() nor poll() are used anyway. > > Happy hacking! > > Christian > >
