[Libwebsockets] CGI on lws

Jaco Kroon jaco at uls.co.za
Wed Feb 24 08:49:27 CET 2016


Hi,

Yes, I concur, vfork() is much cheaper than fork(), it also avoids other
nasty problems, as an example squid currently suffers from an issue
where as an example  I've got a system with 64GB of RAM where it fork()s
to create new authenticators, confiured to use 54GB of in-memory cache,
as soon as that happens and it forks just one new authenticator the vm
commit levels gets exceeded, resulting in the fork() to fail.  I had to
add 64GB of swap to make this work even though the swap is never required.

vfork() is a bit trickier to use though which is why squid hasn't yet
managed the change.

Kind Regards,
Jaco

On 23/02/2016 17:30, Bruce Perens wrote:
> Andy,
>
> posix_spawn() and clone(CLONE_VFORK) are a lot cheaper than fork,
> where available. Fork does a lot of copying that we then throw away.
> Even the copy-on-write version in modern systems does much more work
> than we need.
>
> The preferred way to run interpretive languages from the web, these
> days, is to run the web server as a reverse proxy, as in the
> /proxy_pass/ function of /nginx, /which is documented
> at https://www.nginx.com/resources/admin-guide/reverse-proxy/
> This gets rid of the process start overhead for multiple invocations.
> This is the accepted way to run Rails and PHP, etc. It's also possible
> to code a server that is a reverse-proxy client and handles the task
> of spawning CGI scripts for the main server. This might take some of
> the complication out of the main server thread.
>
>     Thanks
>
>     Bruce
>
> On Tue, Feb 23, 2016 at 3:06 AM, Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>> wrote:
>
>     Hi -
>
>     I am working on adding a cmake-selectable CGI api to lws, basically
>
>     LWS_VISIBLE LWS_EXTERN int
>     lws_cgi(struct lws *wsi, char * const *exec_array);
>
>     LWS_VISIBLE LWS_EXTERN int
>     lws_cgi_kill(struct lws *wsi);
>
>     where the forked process' stdin/out/err is piped on to three slave
>     wsi created in the same service thread as the master: these are
>     managed through the same event loop as everything else, when the
>     process has output, his pipe fd POLLIN fires and there's a user
>     callback where the user code can wire it up to outputting it when
>     the sink socket is writeable.  That happens piecemeal and
>     multitasked according to the combination of server, network and
>     process conditions; the user code in the callback can choose to
>     wire it up to http[s] or ws[s] according to what they want.
>
>     The guts of it work already in my local tree, but there are quite
>     a lot of things to take care about with regard to managing the
>     event loop properly for all cases, as well as deal with POST ->
>     stdin and that might take a while.
>
>     The goal of it is to provide a primitive with which you can easily
>     spawn "io-encapsulated" subprocesses to the network, ie, run cgi
>     like mailman or general scripts or web language interpreters.
>
>     I am curious if potential users of it have any comments or
>     suggestions about this direction, since it's one of decreasing
>     number of missing bits in the lws toolkit from the point of view
>     of it being able to make a generic webserver.
>
>     -Andy
>     _______________________________________________
>     Libwebsockets mailing list
>     Libwebsockets at libwebsockets.org
>     <mailto:Libwebsockets at libwebsockets.org>
>     http://libwebsockets.org/mailman/listinfo/libwebsockets
>
>
>
>
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at libwebsockets.org
> http://libwebsockets.org/mailman/listinfo/libwebsockets

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160224/b1a79bcd/attachment-0001.html>


More information about the Libwebsockets mailing list