[Libwebsockets] CGI on lws

Bruce Perens bruce at perens.com
Tue Feb 23 16:30:32 CET 2016


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
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.



On Tue, Feb 23, 2016 at 3:06 AM, Andy Green <andy at warmcat.com> wrote:

> Hi -
> I am working on adding a cmake-selectable CGI api to lws, basically
> lws_cgi(struct lws *wsi, char * const *exec_array);
> 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
> http://libwebsockets.org/mailman/listinfo/libwebsockets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160223/4f2049e6/attachment-0001.html>

More information about the Libwebsockets mailing list