[Top][All Lists]
[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
Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf
- RE : [lwip-devel] [bug #19162] lwip_sendto: possibleto corruptremoteaddr/port connection state,
Frédéric BERNON <=