[Libwebsockets] polling for file descriptor i/o
andy at warmcat.com
Wed Mar 1 01:29:59 CET 2017
On February 28, 2017 9:05:52 AM GMT+09:00, Andy Green <andy at warmcat.com> wrote:
>On February 27, 2017 8:19:50 AM GMT+09:00, Andy Green
><andy at warmcat.com> wrote:
>>On February 27, 2017 5:17:38 AM GMT+09:00, Per Bothner
>><per at bothner.com> wrote:
>>>On 02/26/2017 11:37 AM, Andy Green wrote:
>>>> How about you also explain what kind of semantics you are looking
>>>from lws around that fd to save us having another round of "that's
>>>what I need"?
>>>Sure. The ldomterm program starts up a child process, with a pty.
>>>When the child process writes to its pty,
>>>input becomes available on the master fd in the ldomterm process.
>>>We need to take this inpur and send it (using lws_write)
>>>to the browser at the other end of the websocket, so that
>>>the browser can display the output.
>>>The current implementation:
>>>starts up a separate thread (function thread_run_command) to listen
>>>to the master fd (using a select near line 185), put it on a queue,
>>>and later the main thread sends it to the server (see case
>>>LWS_CALLBACK_SERVER_WRITEABLE near line 322).
>>>This seems very complicated and inefficient. We should not be using
>>>a separate event loop using a duplicate select. Instead, what I'd
>>>a way to add the master pty file descriptor (client->pty) to the main
>>>select/poll used by lws's event loop.
>>Yeah. Lws already has this kind of thing internally, for CGI
>>Three fd (for cgi stdin/out/err) become children of the socket cgi
>>connection to the remote user, and are managed similar to what you are
>>For that case though, lws definitively owns the fds because it owns
>>cgi. So it has explicit child close processing along with the cgi and
>>the external connection.
>>>A really simple API would be:
>>> lws_add_input_hook (lws, client->pty, callback_function);
>>>The signature of the callback function could match the other callback
>>>functions. It might also make sense for these input-available events
>>>to be handled as a different protocol with an entry in the
>>>struct lws_protocols protocols table. I don't know enough about lws
>>>and design to determine what is the best approach.
>>Since it wants to be externally added to the pollfds table it will
>>to be able to be externally removed, and only closed externally
>>(although if it's still added when lws context is destroyed it may get
>>closed). You may need to do rx flow control on it, and ask for
>>callback when it's writeable... so really it wants a logical wsi
>>it to allow using the normal apis. Otherwise though the wsi is not
>>useful for anything except appearing at the callback.
>>So it seems it boils down to the same kind of adopt api returning a
>>wsi, the existing raw adopt stuff and this needs to allow binding to a
>>specific vhost protocol at adoption time, and an 'unadopt' api to
>>remove it from the pollfds table and destroy the wsi without closing
>>I'll have a look at it during today.
>I implemented this yesterday, including moving the wsi .sock and
>related adopt apis to a union also with the file type, and an enum to
>enumerate the expanded possibilities for the internal adopt api. But I
>think it's a bit unreasonable now to not test it (and be able to
>confirm it ongoing) inside lws test apps somehow, so I'll look at that
I pushed the changes and a new plugin that creates a posix FIFO and manages reading it through the lws event loop.
It's worth looking at that as an example for how to adopt file fds in lws now, if you can filter out the FIFO-specific bits.
>>Libwebsockets mailing list
>>Libwebsockets at ml.libwebsockets.org
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets