>
>  may be written in synchronous way, may block etc.
> So a thread would be spawned and then exit when it has served a single
> request?  Or would it have a longer life?  Is it possible to have a pool
> of
> server threads that service requests?  It would then be possible to
> have something like a message queue where each incoming request
> is dispatched to the pool and the next thread to get the message processes
> the request.


Yes, thread spawns when request comes in, and ends when user callback is
finished.
Thread pool and a dispatcher are needed to sort out performance issues.

But for my knowledge, performance is never a problem for SHTTPD. How many
QPS
are expected on Web GUI frontend for embedded device / home web server ?
My guess, not that many.
So the simplicity is a priority, that's why I would throw away all
performance boost techniques.


I guess I just don't understand how long a thread will live.  Also be
> aware that on RTEMS we really do like to control the number of
> created objects and most systems have hard limits.  So some type
> of thread pool arrangement would work best.  It would also avoid
> flood issues swamping even a UNIX system.


Hmm, this is good point. Currently, SHTTPD can be flooded with large number
of queries (I use "siege" tool for flood test). For each request, SHTTPD
allocates
a connection object on heap, socket to client, and opened descriptor to
file/directory/CGI (whatever is requested). Number of connections is limited
by FD_SETSIZE, as far as I can remember.

RTEMS has real threads -- both POSIX threads and Classic API tasks.
> In RTEMS, POSIX threads is an optional configure time item and Classic
> API tasks are always enabled.


Great.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
shttpd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shttpd-general

Reply via email to