I am actually adopting shttpd core to scalable.c - like way, so it can
be optionally multithreaded. In CVS, "-threads" option is already present,
and is working on UNIX.
Bunch of API functions to load balance connections will be gone, since they
won't
be needed anymore after core went multithreaded.
Also, I think I found the way to fight dreaded busy loop problem, thanks to
your idea
of using control socket.
Here's the problem:
In embedded situation, the callback might decide to wait for some event, and
only then proceed.
In this case, SHTTPD will call the callback in busy loop, eating 100% CPU,
since the callback
did not finished output yet, and it does nothing.
With control socket, it's easy: callback just sets special flag, something
like SHTTPD_SUSPEND,
remembers some opaque pointer and returns. SHTTPD won't call the callback if
SUSPEND is
set, and then when event happens, and user decides to resume the callback,
it calls
shttpd_wakeup(opaque_pointer). This function will actually send a control
message via the
control socket, clearing SUSPEND flag and waking up select() in
shttpd_poll().
The user callback will be called since there is no SUSPEND flag anymore set.
Sweet.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
shttpd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shttpd-general
