libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libmicrohttpd] Select timeout being set to 0


From: Jon Nalley
Subject: [libmicrohttpd] Select timeout being set to 0
Date: Thu, 27 Oct 2011 15:07:30 -0500

Hi,

I am seeing some odd behavior when using MHD_USE_SELECT_INTERNALLY + MHD_OPTION_THREAD_POOL_SIZE.

When a request is handled, my CPU usage goes to 100% (I am running on a PowerPC 405ex - Linux+uClibc).

I was able to determine that MHD_select() in src/daemon/daemon.c is setting the select timeout to 0.

The following check is true, and ltimeout is 0 which causes the timeout passed to select() to be 0.

else if ( (0 == (daemon->options & MHD_USE_THREAD_PER_CONNECTION)) &&
            (MHD_YES == MHD_get_timeout (daemon, &ltimeout)) )

If I use MHD_USE_THREAD_PER_CONNECTION instead of MHD_USE_SELECT_INTERNALLY + MHD_OPTION_THREAD_POOL_SIZE I do *NOT* see the issue.

I took a look at MHD_get_timeout() and noticed I am hitting the following:

if (earliest_deadline < now)
    *timeout = 0;

I also confirmed that if I close my browser, the connections are closed and the select() is once again called with a NULL timeout (blocking forever).

I am not sure exactly what is going on here.  It seems like the browser (I tested with Chrome and Firefox) is keeping the connection open, which causes MHD_get_timeout() to return MHD_YES (and set ltimeout = 0 in MHD_select()) which results in my process effectively entering a "busy loop" calling select with a timeout of 0 repeatedly.  The page has been fully loaded by the browser, so I am not sure why the connections remain "ESTABLISHED" (as reported by netstat -atn).  Perhaps the browser keeps the connections open in order to speed up subsequent requests?

I would appreciate any feedback as to what I may be overlooking and how I can resolve this issue.

Regards,

Jon Nalley


reply via email to

[Prev in Thread] Current Thread [Next in Thread]