RE: [lwip-devel] [bug #19162] lwip_sendto: possible to corrupt remoteaddr/port connection state

[Taranowski, Thomas \(SWCOE\)]

Making the API calls thread safe is, in general, I think a good thing,
so long as it's conditionally compiled.  I don't like to have to add
thread safety overhead when I don't need it.

Any way we go, we should do better in documenting the lwIP way, which is
to respect the 1 netconn per thread rule.  I suppose this is the
preferred design since it avoids the CPU overhead of numerous
protect/unprotect calls within the API calls, and associated program
size costs.

I suspect most developers butt heads with this issue after they've
already done initial design work based on the assumption that the API
calls are thread safe.  If the lwIP way was better documented in the
code, we'd probably here less of this issue.  

This brings up sort of a personal annoyance of mine, and that is the
general lack of documentation within the lwIP source.  The documentation
for some modules, such as pbuf, is awesome, but there are other files
with nothing.  The new user/porter is left wandering around lost in the
weeds.  I've been wanting to commit some documentation only commentary.
I'd like to know if we have a recommended comment format.  If not, I'll
probably keep with a doxygen style.

If I don't here back on a recommended format, I'll just pick what I want
and submit some documentation patches.


 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
On
> Behalf Of Kieran Mansley
> Sent: Tuesday, February 27, 2007 12:54 AM
> To: Kieran Mansley; Rob Stedman; address@hidden
> Subject: [lwip-devel] [bug #19162] lwip_sendto: possible to corrupt
> remoteaddr/port connection state
> 
> 
> Update of bug #19162 (project lwip):
> 
>                 Severity:              3 - Normal => 1 - Wish
>               Item Group:        Faulty Behaviour => Change Request
> 
>     _______________________________________________________
> 
> Follow-up Comment #1:
> 
> You're right about the assumption that there's only one calling thread
per
> netconn.  That is a deliberate decision to keep things simple, and in
most
> cases will be true.  If a resource of any sort is used from two or
more
> threads, it is usually up to the threads to synchronize access to it,
and
> in
> this respect a netconn is no different.
> 
> It does differ to what people might expect though, so perhaps we need
to
> document this aspect of the API better.
> 
> An alternative would be to overhaul the sockets API as you suggest and
> make
> it thread safe.  I think that is unlikely to happen, but leave the
option
> open for others if they wish to do this.
> 
>     _______________________________________________________
> 
> Reply to this item at:
> 
>   <http://savannah.nongnu.org/bugs/?19162>
> 
> _______________________________________________
>   Message sent via/by Savannah
>   http://savannah.nongnu.org/
> 
> 
> 
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel