[Libwebsockets] polling for file descriptor i/o

Andy Green 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 
>>> event
>>> 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
>> https://github.com/warmcat/libwebsockets/issues/778
>> 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
>> https://libwebsockets.org/mailman/listinfo/libwebsockets
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list