LWIP blocking API return value check

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

LWIP blocking API return value check

杨文成(蹊远)

hi, gus

I'm Alibaba engineer from 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.

best regards,
wencheng


_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: LWIP blocking API return value check

goldsimon@gmx.de
Hi,

Am 16.04.2019 um 10:00 schrieb 杨文成(蹊远):

>
> 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.

That's a good idea. This is an aspect of the specification that lwIP
hasn't been designed for, yet. But it shouldn't be too hard to add, as
you suggested.

I'd suggest an SYS_ARCH_INTR as return code, to match "EINTR" of the
opengroup specification we try to implement. This makes error code
matching more clear as well.

As always: patches for this are welcome!

Regards,
Simon

_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel