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

[steinarl]

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.
---

Thanks for the info Simon, hadn't thought of the semaphore signaling.

I think I'll go for skipping the semaphore altogether, from what I
understand it's only used for sequencing, mutual exclusion is ensured
since the tcpip thread does all processing.

b) if you don't wait for completion, you risk flooding the tcpip_threads
message queue!

The background here is that I've already implemented a priority scheme
where the tcpip thread has several input queues, so it is to be
expected that some of them fill up. I've been warned that there could
be trouble related to full mboxes, so I'm looking into that.

c) you will never get an error return value...
In do_send the error condition is stored in msg->conn->err, so in
theory I could get a simultaneous read and write on that variable. In  
addition,
unless some new interaction is introduced, the sender will never know
if the error condition is 'his'.

This is just an idea, don't know if it will work:
- Use the pcb semaphore to protect reads and writes to the pcb error flag

That way the error condition can be written just as it is now. The  
downside is that there is no guarantee that the error is relevant to  
the last   transmission, will probably be reading old errors. But if  
something is really wrong further down in the stack, at least the  
socket layer is notified (after a certain delay).

Any thoughts? Does anyone know how this is solved in other implementations?

Steinar