[Libwebsockets] possible to fork a process per connection (ws server)?
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
>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
More information about the Libwebsockets