[lwip-devel] Re: [bug #26397] SLIP polling support

[Simon Kallweit]

Simon Goldschmidt wrote:
> Follow-up Comment #7, bug #26397 (project lwip):
>
> I thought sio_recv would not block since it is used that way in ppp.c: if it
> returns 0, nothing has been read and a sleep(1) is executed. If it would
> block, this would never happen.

Actually ppp.c uses sio_read() in blocking mode. It uses 
sio_read_abort() to cancel the blocking sio_read() calls.

> However, the sio.h file isn't very well documented (or not documented at all,
> rather) - the only documentation seems to be in the win32 port's sio.c file,
> and sio_recv isn't documented there, too.

Yep, the behavior of the sio functions is badly documented.

> But to me it seems like sio_recv shouldn't block, and if so I think we should
> keep the current behaviour to avoid upgrading problems. That way, we have
> sio_read for blocking mode and sio_recv for non-blocking mode.

Ehm, I think you mixed them up:

u8_t sio_recv(sio_fd_t);
u32_t sio_read(sio_fd_t, u8_t *, u32_t);
void sio_read_abort(sio_fd_t);

sio_recv() must be blocking as it cannot inform the caller that it has 
not read a character!

sio_read() would allow blocking and non-blocking operation as it can 
return a zero length when nothing was received. The availability of 
sio_read_abort() kind of states that sio_read() *can* be used in 
blocking mode, right?

I still think that adding a new method

u32_t sio_read_nb(sio_fd_t, u8_t *, u32_t);

would probably be the best solution. Then all other functions 
sio_send(), sio_recv(), sio_write() and sio_read() could be declared to 
be blocking and only sio_read_nb() would be non-blocking.

Or we could add a parameter to sio_read() or to sio_open() to configure 
the serial for blocking or non-blocking mode.

Simon