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

[Alain M.]

Hi Simon,

address@hidden escreveu:
> What you wrote is correct, except the fix is not that easy: Making the 
> semaphore a counting one would not help much, as you couldn't tell which 
> OP has completed when the semaphore is signaled. The solution would be 
> for each task to access the socket to have an own semaphore if we didn't 
> want to create a new semaphore for each call. So I'm afraid this won't 
> be that easy to fix.

I am new to lwip, but from what I could understand so far, I believe 
that an intermediate solution would be fine for most cases: as the 
socket sends to netcomm, it could be done by a mailbox from the OS, in 
case of FreeRTOS it would be a QUEUE. This is thread safe as it is 
implemented by the OS.

This would allow any thread to write to the same socket. not other 
commands, but this is the most common problem.

> However, I don't think you want to have multiple tasks reading or 
> multiple tasks writing at the same time: the thing most users asking 
> this question is to have one thread reading while another thread writes 
> (aka. full-duplex).

This is really important, specially for blocking reads... but only *one* 
thread needs to read, and write can be solved as above. (just thinking: 
in the case of netcomm, it could just be a queue too)

This only open if the same thread can "manage" the socket (all other 
functions, or only the same as read.

> 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'! :-(

It would be nice if something like that would be included in 1.3.1, even 
if i a somewhat limited manner similar to what I just suggested.

Thanks,
Alain