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