RE: [lwip-users] multithreaded app ...

[Bill Auerbach]

Yeah, I guess if it were easy to do they would have done it :-)

Isn't not blocking on a read a different problem altogether over using netconns 
or sockets in multiple threads?  Or do you mean you would need reading 
semaphores or writing semaphores?  In any case, my suggestion was only written 
because this threading problem comes up often.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Teratux
>Sent: Tuesday, June 22, 2010 10:41 AM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] multithreaded app ...
>
>I think the problem goes a bit farther.  netconn_recv blocks waiting for
>a connection.  Even if I use a mutex to exclude between the threads that
>write and read, how can I use netconn_recv in a way that it doesn't
>block if there's no one sending on the other end ?? Is there anything
>like a timeout for the netconn_recv call ??
>
>Thanks ...
>
>On 06/22/10 08:24, Bill Auerbach wrote:
>> Since this threading problem comes up weekly it seems, would it be a
>lot of effort to add an LWIP_MULTITHREADED option and add the semaphore
>locks in the functions to ensure no reentrancy in lower lwIP code?  I
>would think 2 simple macros that can expand to nothing or semaphore
>lock/unlocks could be added to all of the functions making lower level
>calls.  Or possibly, call a single locking function passing in the
>function pointer to call after locking.  This might be tricky with
>arguments I know.
>>
>> Bill
>>
>>
>>> -----Original Message-----
>>> From: address@hidden
>>> [mailto:address@hidden On
>>> Behalf Of Simon Goldschmidt
>>> Sent: Tuesday, June 22, 2010 5:07 AM
>>> To: Mailing list for lwIP users
>>> Subject: Re: [lwip-users] multithreaded app ...
>>>
>>>
>>> Kesten, Joerg wrote:
>>>
>>>> Additionally we needed to prevent simultaneous calls to "send" even
>on
>>>> different sockets. We added a mutex in the send function itself ...
>>>>
>>> This shouldn't be necessary. If it is, there's a bug which should be
>>> fixed. Could you provide more details on what exactly went wrong with
>>> parallel sends from different netconns/sockets?
>>>
>>> Simon
>>> --
>>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
>>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>>>
>>> _______________________________________________
>>> lwip-users mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users