[Libwebsockets] polling for file descriptor i/o
andy at warmcat.com
Sat Feb 25 09:11:11 CET 2017
On February 21, 2017 9:59:52 AM GMT+09:00, Andy Green <andy at warmcat.com> wrote:
>On 02/19/2017 05:32 AM, Andy Green wrote:
>> On 02/18/2017 01:45 AM, Per Bothner wrote:
>>> ldomterm waits for output from the child process by running select
>>> a separate thread: See the code in:
>>> This works, but it seems clumsy and wasteful, since lws has its own
>>> loop using select/poll.
>>> Is there any mechanism to add a file descriptor to the lws event
>>> loop and have a callback function fire when data arrives?
>>> Perhaps this could use a new pseudo-protocol?
>>> (Not a big deal, but maybe worth thinking about if changing
>>> the VFS data structures.)
The VFS changes I had in mind are now also done and pushed on master.
As it says in REAME.coding.md now
### Changes from v2.1 and before fops
There are three changes:
1) Pre-2.2 fops directly used platform file descriptors. Current fops returns and accepts a wrapper type lws_fop_fd_t which is a pointer to a malloc'd struct containing information specific to the filesystem implementation.
2) Pre-2.2 fops bound the fops to a wsi. This is completely removed, you just give a pointer to the fops struct that applies to this file when you open it. Afterwards, the operations in the fops just need the lws_fop_fd_t returned from the open.
3) Everything is wrapped in typedefs. See lws-plat-unix.c for examples of how to implement.
There's a void * member in lws_fop_fd_t which is entirely for use by the implementation.
Types that were explicit C types before are now typefeds based on ssize_t / size_t (ahhaha windows has no ssize_t... no worries...)
>> There are socket adoption APIs in lws, but they currently only adopt
>> stuff expected to be in http or https logical protocol.
>> There's another guy asking for this on github
>> but he wants something a bit less reasonable related to being able to
>> accept arbitrary raw connections on the same listen socket as http -
>> and https . However doing that also requires raw adoption you want
>> underneath. So I will try to provide it.
>I pushed an untested patch adding this on master.
>The deal with it is there is a new adoption api
>struct lws *
>lws_adopt_socket_vhost2(struct lws_vhost *vh, lws_sockfd_type
> int allow_ssl, int raw)
>this lets you control whether ssl will apply (if the vhost is set up
>it), and if the adoption is for a raw socket.
>If allow ssl and the vhost is configured for it, then lws will
>the ssl link on the connection first.
>The wsi experiences these callbacks
> LWS_CALLBACK_RAW_RX = 59,
> /**< RAW mode connection RX */
> LWS_CALLBACK_RAW_CLOSE = 60,
> /**< RAW mode connection is closing */
> LWS_CALLBACK_RAW_WRITEABLE = 61,
> /**< RAW mode connection may be written */
> LWS_CALLBACK_RAW_ADOPT = 62,
> /**< RAW mode connection was adopted (equivalent to 'created') */
>once it's adopted lws owns the fate of the socket fd including logical
>closing of it. Otherwise it should hopefully work as you would expect.
>The patch also adds CONNECT method aimed at the guy on github, but
>that's not wired up yet and I am not sure if it's a good idea atm.
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets