[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] sys_arch_mbox_fetch() implementation for FreeRTOS

From: massimiliano cialdi
Subject: Re: [lwip-users] sys_arch_mbox_fetch() implementation for FreeRTOS
Date: Tue, 21 Jun 2022 12:37:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1


the setsockopt(SO_RCVTIMEO) POSIX call contemplates the possibility of imposing 0 as the 'timeout' parameter, and in that case that socket becomes non-blocking (See, for example, https://stackoverflow.com/questions/49706883/disable-socket-timeout-via-setsockopt).

The socket API of lwip does not match this behavior. Or am I mistaken?
Would it be possible to impose the underlying netconn as nonblocking (using e.g. `netconn_set_nonblocking()`) when the timeout is 0? Am I oversimplifying?

best Regards


Massimiliano Cialdi

Powersoft S.p.A.
Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
OFFICE:    +39 055 7350230


On 20/06/22 21:17, goldsimon@gmx.de wrote:
Am 20.06.2022 um 11:22 schrieb massimiliano cialdi via lwip-users:

I am using lwip 2.1.3 and contrib 2.1.0.
in the ports/freertos/sys_arch.c file there is the sys_arch_mbox_fetch()
function, in which there is the timeout_ms parameter.
Given the name I expect the sys_arch_mbox_fetch() function to be
blocking for a maximum time corresponding to timeout_ms milliseconds.
I see this piece of code, though:

   if (!timeout_ms) {
     /* wait infinite */
     ret = xQueueReceive(mbox->mbx, &(*msg), portMAX_DELAY);
     LWIP_ASSERT("mbox fetch failed", ret == pdTRUE);
   } else {

I wonder why I should wait infinitely if I set the timeout to 0 (so I
want it non-blocking)? is this a bug?

See the documentation of that parameter in sys.h:
@param timeout maximum time (in milliseconds) to wait for a message (0 =
wait forever)

It's a bit unfortunate, but it has been like that since forever (0 =
wait forever). The code uses sys_arch_mbox_tryfetch() when it does not
want to block at all.

In fact, it happens to me occasionally (I have yet to figure out the
conditions) that even though I have the timeout set to 0, re-read with
lwip_getsockopt(SO_RCVTIMEO), the task blocks indefinitely while waiting
for a message in the queue.

That would be odd. Please report a fix if you find one.


lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]