Hi,
I am working on a non-blocking UDP send through the sockets interface.
Based on what I've seen in the source I figure there are two potential
blocking points in tcpip_apimsg:
- sys_mbox_post, easy fix: replace with sys_arch_mbox_trypost
- sys_arch_sem_wait(apimsg->msg.conn->op_completed, 0);
This one is harder I guess, but it seems an easy fix is to just not
wait for the semaphore to be signaled.
My question is, where will I create a mess if I just ignore the signal
and return straight away?
The sending thread won't know if the packet is ever transmitted, but
then again UDP is unreliable.
I know other signals go through tcpip_apimsg as well, so any problems
with those and I'll just single out the sending as a separate function
in tcpip.h.
I'm supposed to make select work together with this non-blocking send
as well, could that make matters more complicated?
- Steinar
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
