Re: [lwip-users] the sequentiality of the lwip stack

[Pomeroy, Marty]

 

 >>  BUT never can t1 and t2 both access s1 or s2. 

Practically speaking, a socket is a stream of data, and it doesn't make sense for tasks to contend for that stream.  You would need to provide additional coordination mechanisms at the application level to make sure t1 is not getting t2's data from s1, and vice versa.  If you are providing that coordination mechanism at the application level to prevent data contention, then there will be no problem in the stack anyway.

 

The only situation I can think of where this might be "useful" would be a socket that the application never receives from and only sends to.  So it might be "nice" to send on one socket from multiple threads.  But you can provide a simple coordination mechanism to keep the requests single threaded.  Or just open two sockets.

 

Can someone provide a common situation which requires one socket used on multiple threads?  If not, given the effort that would be needed, the lack of requirement, and the simplicity of working with lwIP as it is... 

 

Marty