[Libwebsockets] possible to fork a process per connection (ws server)?
daveh at beachdognet.com
Mon May 20 22:46:49 CEST 2019
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..
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> wrote:
> Wondering if it is possible to have a ws server where I am able to fork
> 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 global
> mutex in a single multithreaded process would just slow everything down
> 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