Re: [lwip-users] 1.4 rc1 non-blocking issues

[Kieran Mansley]

On 30 Nov 2010, at 16:15, Yoav Nissim wrote:
> 
> 1. ERR_WOULDBLOCK is treated as a FATAL error - it seems as if someone
> forgot to update the ERR_IS_FATAL macro when the error code was added. A
> non-blocking operation that sets the conn error to WOULDBLOCK (e.g
> send() and recv() ) renders the socket unusable. Our workaround was to
> use ERR_WOULDBLOCK in the ERR_IS_FATAL macro instead of ERR_VAL.

I agree that looks wrong.  I'm sure it was correct in the past.  I'll make sure 
this is fixed before 1.4.0 is released.  If you could file a bug for this on 
savannah it would help.

> 2. As far as we know, EMSGSIZE is not a valid return code for send() on
> a STREAM socket. netconn_write does not return the number of bytes
> processed and cannot perform partial sends. This makes an application
> that uses select run in tight loops since select returns writable, but
> send [working on an all or nothing assumption] returns an error
> (EWOULDBLOCK)

I'd like to see lwIP updated to support partial sends (which I think would 
solve this problem) but it won't happen before 1.4.0.  A task on savannah would 
again be very helpful, if there's not one already - I think this might have 
been discussed before.

> 3. connect has several problems:
> 
>     a. connect sets sock->err to EINPROGRESS. When select returns
> writable, getsockopt(SO_ERROR) will never let us know what happened [i.e
> no access to conn->err] since getsockopt(SO_ERROR) does not return the
> error value when sock->err is not 0 (it is set to EINPROGRESS). It seems
> to me the non-blocking path lacks the propagation of the connect result
> to sock->err (which does happen when using a blocking call).
> 
>     b. getsockopt(SO_ERROR) - behaviour according to Posix is to return
> and clear the _pending_ error for the socket (if one exists). instead
> getsockopt returns the last socket call error once. If additional calls
> are made netconn's last error is returned repeatedly.
> 
>     c. if connect is called again while a previous non-blocking connect
> is being processed, ERR_ISCONN is assigned to conn->err [which by the
> way translates to an errno of -1]. Now, if the connection succeeds,
> do_connected will not be able to set conn->err to ERR_OK since it checks
> for ERR_INPROGRESS. To make things worse, ERR_ISCONN is treated as a
> FATAL error, and will therefore render the socket unusable. According to
> Posix, EALREADY should be returned while a connect is in progress, and
> EISCONN should be returned when a socket is connected.

We'll need to look into those in more detail.

> 4. lwip_select seems to be susceptible to race conditions and has issued
> many ASSERTs as well as crashed.

These sounds like you're using a socket from two different threads (one calling 
select(), the other calling close()).  Unfortunately this style of operation 
isn't supported in lwIP.

Kieran