lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : [lwip-devel] [bug #19162] lwip_sendto: possibleto corruptremoteaddr


From: Frédéric BERNON
Subject: RE : [lwip-devel] [bug #19162] lwip_sendto: possibleto corruptremoteaddr/port connection state
Date: Sun, 22 Apr 2007 23:51:10 +0200

I will continue and terminate that Thrusday, when I will back to the office. 
I'm currently in London for NXP presentation and training, and it seems that 
several people are interest about lwIP for Trimedia processor (the platform I 
use)...
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Jonathan Larmour
Envoyé : vendredi 20 avril 2007 16:35
À : lwip-devel
Objet : Re: [lwip-devel] [bug #19162] lwip_sendto: possibleto 
corruptremoteaddr/port connection state


Goldschmidt Simon wrote:
> I'd rather have the sockets API call tcpip-thread directly, but that
> again would mean redundant code.  And while I don't think that would be
> bad regarding Code size (who uses socket and netconn API in one
> application?),

I don't think anyone writing a whole new application would, but if you were 
reusing existing modules you might. It's certainly unlikely, and probably 
not something we need to care much about though.

Note that this problem is essentially equivalent to sorting out the 
netconn's thread-safety so that different threads can operate on the same 
socket. I think Frederic is looking at this, although I would expect the 
result would be something inevitably a bit more heavyweight, and so likely, 
optional.

> it would mean maintaining similar code twice (and netconn
> API bugs might go undetected as I think socket API is the API more 
> widely used).

I don't believe the netconn API comes close to being unused.

> So I'm not saying to change anything, right now. But as I said, I'd 
> like to look into the performance gain for sockets API on this and if 
> it's big, we can
> talk about this again...

Well, we know you'd save one function call. I'm not sure if it would be 
much beyond that.

>> this.  If people want a higher performance zero-copy API,
>> we've got one in the form of our raw API.
> 
> Are you saying to drop netconn API? I'd that like since I don't use 
> id, but talk to Jonathan about that ;-)

Only because the netconn API turns out not to support zero-copy well, but 
as it happens I'm now (today) working on http://savannah.nongnu.org/task/?6735

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-devel

Attachment: Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf


reply via email to

[Prev in Thread] Current Thread [Next in Thread]