sorry,
my fault
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
On 2022-06-21, massimiliano cialdi via lwip-users wrote:
> 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,
>
Am 21.06.2022 um 12:37 schrieb massimiliano cialdi via lwip-users:
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,
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
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()
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
