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

[Atte Kojo]

Kieran Mansley wrote:
> 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.
>   
Yes, I seem to be drifting more and more off-topic in this thread ;-). I 
didn't mean to say that using zero-copy and TCP would be a very good 
idea. I was just pointing out that everything that can be done using 
netbufs and netconn API can easily be done using socket API, with minor 
nonstandard changes (i.e. some new flags) to the API.
> > 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.
>   
Sorry, I didn't probably express myself as clearly as I wanted. I didn't 
mean to berate the socket API in any. We're using it in a production 
system and it works very well. My main point was that I don't really see 
the reason why netconn API and sockets API should continue to be 
developed in parallel since both implement essentially the same 
functionality. My opinion is that the two could be merged so that 
sockets API would replace the netconn API. And raw API would continue to 
be developed as before.
> 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.
>   
Our version of lwIP has been completed for quite some time now and is in 
a maintenance/bugfix phase for the current product line where it is used 
so I wouldn't want any major changes either :-). And unfortunately due 
to our nonstandard hardware, our version differs quite a lot from the 
vanilla version.

But, (a BIG) if we're starting development of a new product utilizing 
lwIP and a decent microcontroller, I'd be more than happy to help in 
developing a new version of lwIP. I think that overall it is a very nice 
system, but could use a bit of cleanup here and there.

- Atte