[Libwebsockets] possible to fork a process per connection (ws server)?

Andy Green andy at warmcat.com
Mon May 20 23:50:39 CEST 2019

On May 20, 2019 1:46:49 PM PDT, Dave Horton <daveh at beachdognet.com> wrote:
>The model I had in mind was the typical (“simple”) model of: parent
>accepts a connection, forks a child to handle it, and the child reads
>from that socket.
>I think the direction you outline is somewhat different, if I
>understand it — the parent continues to read all the data from all the
>connections (sockets), creates a thread per connection, and that thread
>forks a child.  The only thing is that in my case the websocket is used
>for ongoing streaming of data from client to server — when the server
>creates the thread it does not have all of the data to pass to the
>client, which then goes off and does “its thing”.  The client rather
>has to process streaming data for a relatively long-lived (in the 10s
>of minutes) connection.  I was hoping to implement the “simple” model. 
>If the server is still reading all of the data on behalf of all of the
>clients, then I guess I need to create a pipe or something to send it
>to the client..

What you're describing is cgi... lws also supports it.


>On May 20, 2019, at 4:25 PM, Andy Green <andy at warmcat.com> wrote:
>On May 20, 2019 12:58:23 PM PDT, Dave Horton <daveh at beachdognet.com>
>> Wondering if it is possible to have a ws server where I am able to
>> a new process per incoming connection, and the service thread in that
>> process takes over that connection.  I realize there are a lot of
>> alternative ways of doing things, and I would not want to do it this
>> way either, except that I have to process the incoming audio with a
>> 3rd-party library that is not thread-safe.  I’m afraid having a
>> mutex in a single multithreaded process would just slow everything
>> so for this need it would seem better if I could somehow fork
>> processes..
>Sure, you can do what you want once you have the thread.  Itbwouldn't
>'take over' anything... the forked process would usually exec your
>application you want to run and the parent thread would continue
>monitoring the subprocess state and returning output etc.
>But it's best if the thread / process does not 'go away' for the
>duration of the processing, but uses the 'checking in' stuff. 
>Otherwise it will always dumbly cokplete the work before discovering
>the wsi that's waiting on it went away a while ago.
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list