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,<imeout)) )
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