[Libwebsockets] polling for file descriptor i/o
andy at warmcat.com
Tue Feb 28 01:05:52 CET 2017
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 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
>>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 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
>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
>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 today.
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets