[Top][All Lists]
[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, <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
- [libmicrohttpd] Select timeout being set to 0,
Jon Nalley <=