[Libwebsockets] polling for file descriptor i/o

Per Bothner per at bothner.com
Fri Mar 3 02:40:35 CET 2017

On 03/01/2017 03:04 PM, Andy Green wrote:
>> But I want the same user object for LWS_CALLBACK_RAW_RX_FILE as I want
>> for the WS protocol handler.  At least the way it is currently done:
> They are two different wsi.  Because they manage two independent descriptors.
> As I mentioned cgi is done similarly inside lws already.  3 fd wsi are children of one http mode wsi.  If you bind the wsi like that, parents can find their children and a child wsi can get a pointer to his parent.

>> LWS_CALLBACK_RAW_RX_FILE reads (from the pty child) into a buffer, but
>> waits to write the data out on the WebSocket.  I could defer the read
>>from the child until the WebSocket is writeable, but would that be
>> right?
> Yes, in fact it's ideal, but you will have to use the rx flow control api to modulate POLLIN, otherwise it will keep tapping you on the shoulder until you consume the read data when the ws wsi is writable.  You'd reenable the file desc flow control after you read as much as you wanted, it'll come back around if there's more, at whatever rate the outgoing ws connection can cope with.

So how do I set state when LWS_CALLBACK_RAW_RX_FILE triggers (when
input is available from the pty) so I can read that state when
LWS_CALLBACK_SERVER_WRITEABLE is called? They have to share some
data structure (I might be able to manage with a single bit,
but I need at least that), but it's not clear to me how to do that.

More generally, a suggestion for the libwebsockets.h:
It takes care to documents all of the functions, but where
is the documentation of the types?  What is a 'struct lws'?
What is a 'struct lws_host'?  What do they represent, in the
sense of "there is one of each 'struct X' for each Y"?
Statements like "a struct X owns/manages a set of struct Y"
would be helpful.

I'm not really a networking guy, so I'm not clear on all
the terminology.
	--Per Bothner
per at bothner.com   http://per.bothner.com/

More information about the Libwebsockets mailing list