[Libwebsockets] polling for file descriptor i/o

Per Bothner per at bothner.com
Wed Mar 1 23:41:51 CET 2017


On 03/01/2017 01:33 PM, Andy Green wrote:
>
>
> On March 2, 2017 6:07:35 AM GMT+09:00, Per Bothner <per at bothner.com> wrote:
>> I tried using lws_adopt_descriptor_vhost:
>>      lws_adopt_descriptor_vhost(lws_get_vhost(wsi), 0, fd, "domterm");
>>
>> I do get a LWS_CALLBACK_RAW_RX_FILE callback, and I can read valid
>> data from thefrom the pty.
>
> Good...
>
>> However, the 'user' parameter in the callback function is NULL.
>> I kludged around it using a static variable, but I need a better
>> solution, obviously.  Could/should lws_adopt_descriptor_vhost
>> take an extra user_data parameter?
>
> We can do that, or have it allocate (and free) based on the user data size given in the protocols struct... does the latter make any trouble if we fixed it that way?

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:
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?

>> In case LWS_CALLBACK_RAW_RX_FILE I read the data into a buffer, and
>> then
>> call lws_callback_on_writable(wsi).  I do *not* get a
>> LWS_CALLBACK_SERVER_WRITEABLE
>> event; instead I get a LWS_CALLBACK_RAW_WRITEABLE_FILE. Calling
>
> That bit is good... you might have the same protocol callback handling ws and raw file side, so they have different callback reasons.

That doesn't seem right.  I'm not trying to write to the raw file; I'm trying
to do an lws_write when the WebSocket server is writeable.  So
LWS_CALLBACK_SERVER_WRITEABLE makes sense and WS_CALLBACK_RAW_WRITEABLE_FILE doesn't.
I'm trying to copy - reading from a raw file descriptor, and writing to the browser
using WebSockets.

>> lws_write
>> in a LWS_CALLBACK_RAW_WRITEABLE_FILE fails.
>
> ... but this isn't I guess it's some missing handling somewhere.
>
> Is there a clue what happens?  You should use LWS_WRITE_HTTP as it stands (nearest thing to raw atm)

HTTP is not involved (except to the extent that WebSockets is based on HTTP).
Once the resources (html, css, js) have been loaded, it's all WebSockets.

I can single-step the lws_write with gdb - but I'm really doubtful that WS_CALLBACK_RAW_WRITEABLE_FILE
is correct.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/



More information about the Libwebsockets mailing list