Re: [lwip-users] Implementing non-blocking lwip_sendto, UDP only

[address@hidden]

address@hidden wrote:
> 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
>   
You can do that, but this will only block if you are flooded by RX 
packets! Unless you implement your second idea, of course :-)
> - 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?
>   
a) the semaphore will be signalled again and again and might eventually 
reach its limit. If the arch layer is written well, it will assert at 
this place. You will have to trywait for the semaphore at one place to 
count it down again or change the corresponding send function in 
api_msg.c to not post on the sem when done.
b) if you don't wait for completion, you risk flooding the tcpip_threads 
message queue!
c) you will never get an error return value...

Other than that it _could_ work.
> 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.
>   
TCP send _must_ wait until finished, so you will have to explicitly use 
a different mechanism for UDP sending, only.
> I'm supposed to make select work together with this non-blocking send  
> as well, could that make matters more complicated?
>   
I'm afraid I can't really help with select :-(

Simon