Re: [lwip-devel] [bug #19162] lwip_sendto: possible to corruptremoteaddr/port connection state

[Jonathan Larmour]

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