[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [task #6683] Document lwIPs thread safety requirements
From: |
Frédéric Bernon |
Subject: |
[lwip-devel] [task #6683] Document lwIPs thread safety requirements |
Date: |
Mon, 26 Mar 2007 12:48:17 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 |
Follow-up Comment #1, task #6683 (project lwip):
I'm ok and have start to study several points. First, I think we have to
define what in lwIP have to be thread safe. I think that we can tell that :
- lwIP core isn't thread safe. If we have to use lwIP in a multithread
environment, we should (or HAVE TO) use "upper" layers (netconn or sockets).
raw api's need to protect themselft the core.
- some upper operations have to be handled directly by application: socket,
bind, connect, setsockopt and close. I don't think it's the lwIP role to
handle that (by example, it will be difficult to know if a "int socket" is
always same between close/socket calls:
T1
int s1=socket() (tell s1=5)
T1,T2
use s1 with send,recv (ok, it could be possible).
T2
closesocket(s1)
T3
int s2=socket() (and... it could be s2=5)
T1
send(s1) !!!! Problem, s1 would not the same proto/port than the first we
open, but only application can know that !!!!
- some operations can be transform to thread-safe : recv, recvfrom, send,
sendto... To enable fullduplex protocols. We have to move some processing
from netconn/sockets to api_msg, but it's possible, and even can be
faster...
- I don't use select, and I think it is a special case (lot of code is only
use for this function, and could/should be disable)...
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/task/?6683>
_______________________________________________
Message posté via/par Savannah
http://savannah.nongnu.org/