Re: [lwip-devel] lwip deadlock in tcpip_apimsg using FreeRtos ST Arm Port with lwip sockets

[Jonathan Larmour]

Alain M. wrote:
> I have been thinking abou this and a simple idea struck me !!!
>
> There is some talk about creating a new socket interface, so why not 
> make both things toghether:
>
> a new socket api that is thread safe !!!
>
> That way, compatibility will not be an issue, as it would be just one 
> more compile time option (thare already 2 sockets), and at the same time 
> it can have a new pre-requisite from the OS. And it can be used as an 
> alternative only by those who need it...

The issue with supporting multiple sockets isn't compatibility, it's how 
to do it efficiently and with low memory overhead. A naive solution would 
involve mem_allocing semaphores every time, for example. It would work but 
suck :-).

And I'm sure I wouldn't be the only one thinking that adding a fourth API 
to lwIP, with lots of overlap with an existing one, doesn't sound like a 
maintainable solution. It should be a replacement, and so shouldn't take a 
non-trivial step backwards, including with respect to memory footprint 
(which may mean configurable behaviour).

Simon wrote before that:
> This could be easier to solve if we had one semaphore for read actions and
> one for write actions. Still I have to disappoint you about a planned fix
> for this. The current position of lwIP is just 'not supported'! :-(

I didn't say this in my earlier reply in this thread, but I'm not sure how 
you can be sure you are waking up the correct thread with a single 
semaphore for each of reads and writes. You might wake up a thread which 
had attempted to write data, but that data has not yet been accepted by 
the stack due to being out of send buffer space, for example. You'd want 
to wake up the oldest waiting thread whose write has actually made it into 
the stack. Hence my suggested alternative.

Reads are different as I think we don't have to care as much about 
ordering, although if e.g. two threads do a read(fd, buf, 2048), are they 
guaranteed a _contiguous_ 2k chunk from the stream? Or is it ok for TCP 
segments to be sent to different threads before the full 2048 read is 
complete in either? I don't know if there's any required, or at least 
desirable behaviour here.

I don't think any of this is an easy problem to solve, in the existing API 
or a rewrite.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine