Re: [lwip-users] Why does sys_sem_wait_timeout exist?

[Kieran Mansley]

On Wed, 2007-02-28 at 08:26 +0200, Atte Kojo wrote:
> As far as I understand, when running in flat memory "zero-copy" is more 
> of an illusion than anything else. Right now writes/sends on UDP sockets 
> with socket API are already blocking and don't copy any data between 
> pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be 
> made "zero-copy" also with a non-standard option for send (like 
> MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the covers).

This is perhaps a bit of a tangent to your point but implementing zero-
copy writes for TCP through the sockets API is very difficult unless the
application can guarantee that the data are static and it will never
modify the buffers it passes in.  The sockets API can't make this sort
of guarantee (and so it would have to be a modified API as you suggest)
and the number of applications that *can* make that sort of guarantee
without using vast quantities of memory is very small.  As such I don't
think this specific change would be the best use of our time.
Particularly, as you point out, that for a stack such as lwIP doing the
copy during the checksum is not a big deal, and we're not looking for
stella performance as our main goal.

> PS. The main reason I'm so strongly advocating this is that I don't like 
> having a nonstandard API where a standard one would do. Using a socket 
> API that behaves just like its real counterpart is a lot easier for new 
> users (and us old ones also). Plus the netconn-API lacks select() which 
> makes single-thread servers a gazillion times easier to implement.

I agree with you that the sockets API as it standards is incomplete and
non-standard, but in many cases has proved to be "good enough" for many
people.  It's pretty stable, but I'm pretty sure it's not bug-free.  It
would be nice to be able to throw it away and start again with something
built directly on the raw API (I did this for my own project when first
working with lwIP, but it was so specialised as to be of no use to
anyone else) as we could undoubtedly do better, but we'd lose some of
the current stability and we'd need more active developers than we
currently have.

I see lwIP as pretty much stable and mature, and so I'm fairly
conservative about major code changes or rewrites.  The sort of thing
you're proposing would be great for a version 2, but I don't anticipate
there being a version 2 any time soon.

Kieran