hi, gus
I'm Alibaba engineer from AliOS Things
<https://github.com/alibaba/AliOS-Things> RTOS team, we have integrated
LWIP as the default net protocol. Recently we are developing micro
kernel, to support LWIP API as user space system call.
Normally, system calls like recv(), send(), accept() should be
cancellation points, that's to say, user space task can be cancelled
when it reaches the cancellation points. To this end, if the task is
blocked within these APIs, it can be waken up by signals, the return
code of the blocking function should be checked to decide what to do next.
for example:
api/api_lib.c: netconn_recv_data(), if the task is blocked at
sys_arch_mbox_fetch(), waiting for new package, then a signal is sent to
the blocked task, the task will resume and return
from sys_arch_mbox_fetch() with return code indicating it's waken up by
signals other than timeout or normal return.
However, I checked the LWIP APIs, there are a couple of places where the
return code of blocking functions are ignored. it makes it difficult to
handle the case that the task is waken up by signal.
we suggest LWIP adding another error code, for example
SYS_ARCH_WAKEUP, to indicate the blocking function is waken up, and
handle this error case properly.