[Libwebsockets] polling for file descriptor i/o

Andy Green andy at warmcat.com
Mon Feb 27 00:19:50 CET 2017

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 for
>from lws around that fd to save us having another round of "that's not
>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
>This seems very complicated and inefficient.  We should not be using
>a separate event loop using a duplicate select.  Instead, what I'd like
>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 handling.

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

For that case though, lws definitively owns the fds because it owns the 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 need 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 behind 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 the fd.

I'll have a look at it during today.


More information about the Libwebsockets mailing list