[Libwebsockets] surprise when using equivalent file descriptors

Per Bothner per at bothner.com
Wed Nov 4 20:32:42 CET 2020

I just ran into a confusing bug.  I may have
already found a fix, but I'm not sure if it's the right fix.

DomTerm uses lws for websockets, https, plain sockets, and file descriptors.
Specifically, it wraps logical stdin/stdout/stderr using lws_adopt_descriptor_vhost.
There are some complications because "logical" stdin/stdout/stderr
may be proxied over either ssh or a Unix domain socket, but the
problem I encountered is when stdin/stdout are connected to the terminal (pty),
created before domterm starts up.  Since they have different file descriptors
(0 and 1) domterm calls lws_adopt_descriptor_vhost once for each.

So what seems to happen is I get RAW_RX_FILE callback on the lws
corresponding to fd 0 - and then I get another RAW_RX_FILE callback
on the lws corresponding to fd 1.  The later fails with read returning -1,
with errno=11=EAGAIN, which confused me until (I think) I figured out
the issue and fix.

The obvious fix once I realized the failure was EAGAIN was:

         n = read(...);
         if (n < 0 && errno == EAGAIN)
             return 0;
         if (n <= 0)
             return -1;
         return handle_input(...)

That seems to work - but perhaps it wrong to create 2 different lws
instances for distinct file descriptors that are dup'd to each other?
It may be difficult to detect this situation, but doing raw
synchronous writes to stdout (without using a struct lws)
is unlikely to hang or cause other problems, especially if
I restrict it to the isatty(1) case.
	--Per Bothner
per at bothner.com   http://per.bothner.com/

More information about the Libwebsockets mailing list