hello, 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 Max Massimiliano Cialdi FIRMWARE ENGINEERING PROFESSIONAL LEADER Powersoft S.p.A. Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy OFFICE: +39 055 7350230 <http://www.powersoft-audio.com/en/>[cid:PS_553e4174-d089-4113-aa68-7863aa6108ea.png]<http://www.powersoft-audio.com/en/> [cid:FB_c651e92c-f558-4470-9dc8-0cde2dc49cf4.png] <https://www.facebook.com/powersoft> [cid:Teams_6088ac53-fdc7-460a-97b3-533e03f1ad3d.png] <https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cia...@powersoft.com> [cid:IN_2180daad-e9b1-4c84-9ac3-d130a49ed1c3.png] <https://www.linkedin.com/company/powersoft> <https://www.linkedin.com/company/powersoft> [cid:YT_c74db1a3-a814-4e66-b04f-15ff9bd7940d.png] <https://www.youtube.com/user/powersoftaudio> <https://www.youtube.com/user/powersoftaudio> [cid:IG_b8aafa87-2c84-4406-9c9e-91da1b7684d0.png] <https://www.instagram.com/powersoft.audio/> <https://www.instagram.com/powersoft.audio/> <http://www.powersoft-audio.com/en/> On 20/06/22 21:17, goldsi...@gmx.de<mailto:goldsi...@gmx.de> wrote: Am 20.06.2022 um 11:22 schrieb massimiliano cialdi via lwip-users: hello, 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. Regards, Simon _______________________________________________ lwip-users mailing list lwip-users@nongnu.org<mailto:lwip-users@nongnu.org> https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
