Re: [libmicrohttpd] Stuck Single Threaded

[Christian Grothoff]

On 05/07/2014 05:49 PM, Kenneth Mastro wrote:
> 
> 
> Another question, though, since you brought it up.  My preferred
> threading mode is select (or maybe epoll, since I'm on Linux - haven't
> tried it yet) with a thread-pool.  My past development experience leads
> me to assume that is the best combination of efficiency and performance,
> in general.  I haven't seen any problems with doing it this way, but I'm
> not using the suspend/resume stuff.
> 
> However - Your message implies there could be complications if I go that
> route.

Actually, I didn't try to imply complications down that route, just that
some developers may find it easier to write a blocking routine to
generate the resulting webpage using a thread per connection instead of
using thread pools and suspend/resume.

> Should I use the built-in suspend/resume stuff even if I'm using
> a thread pool, or is it ok to just pause one of the MHD threads for the
> long-poll?

If you use a thread pool you must use suspend/resume, otherwise all
other connections served by the thread in the thread pool will be
blocked for the duration of the long-poll, which is not what you want.

> Seems like it should be fine unless there's something funky
> about those threads or their management.
> 
> I'm sure I could save some memory and task switching by
> suspending/resuming, but I don't think it's worth the extra complication
> if there isn't some inherent problem with the way I'm doing it.

There is a big difference between thread pool (having many threads, each
of which serves many requests concurrently using select/poll/epoll), and
using a fresh thread for each connection.  If you use
a thread pool, you must suspend/resume, if you use a thread per
connection, you're allowed to just block.

> I don't have to worry much about the number of simultaneous users - I'm
> putting a cap on it at 10 users, with a maximum of 1 long-poll each, and
> I've set aside 20 threads in the pool.  Should be more than enough. 
> Memory use is not a big concern as long as it's not obscene.

If you have at most 10 users, I think starting a thread per connection
is fine.  Thread pools become interesting if you have thousands (or
tens of thousands) of concurrent requests (i.e. per second).  In that
case, a thread pool is just overkill anyway.

Now, using 20 threads in the pool with 10 users makes it unlikely that
one thread will actually have to serve two connections at the same time,
so I suspect right now you have a subtle bug where under certain
circumstances a long-poll'ed connection will cause another unrelated
request to 'hang'.

The easiest change is probably to move to a thread-per-connection,
which will be trivial to do and should result in pretty much the same
performance (for your scenario).

Happy hacking!

Christian

0x48426C7E.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature