lwip-users
[Top][All Lists]
Advanced

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

Re: RE : RE : [lwip-users] managing storage problems.


From: Jonathan Larmour
Subject: Re: RE : RE : [lwip-users] managing storage problems.
Date: Tue, 30 Oct 2007 15:05:45 +0000
User-agent: Thunderbird 1.5.0.12 (X11/20070530)

Frédéric BERNON wrote:
> I'm agree, we should solve that in the stack, and SO_RCVBUF is a good
> solution for me (before/after 1.3.0 ?? To be honest, I'm not sure). I'm
> also in flavor to redesign mailbox model, by adding a "size" parameter
> to sys_mbox_new (by example, the netconn::mbox doesn't really need to be
> larger than 1, of course, a semaphore could be better),

Be warned that some OSes have fixed mailbox sizes. Any design would need to
 allow for that. Embedded systems favour static objects with deterministic
access. Dynamic sizing loses that.

For example, eCos has both sorts so it _can_ be done, but the variable size
mailbox implementation is bigger + slower + non-deterministic.

> and by adding return values to sys_mbox_post (to enable to handle the full
> mbox case).

That's definitely the way forward, and I would have thought would even be
the best workaround for Shai - not to do everything and check errors for
every sys_mbox_post call, but just the calls he cares about (i.e. in
recv_udp). I don't think it would be too difficult to just do that.

Or an alternative workaround is to add a sys_arch_is_mbox_full() function
in the sys_arch part of his port and call that to check before doing the
sys_mbox_post in recv_udp. Even less clean, but perhaps less code to change.

> The main "problem" is to share between application thread and
> tcpip_thread a "byte counter". I think it will be better to include it
> directly in the mailbox model (a sys_mbox_getcount, and something like a
> "bytesize" parameter in sys_mbox_post),

Not every mailbox needs that. I would have thought that, where needed, it
could just be kept alongside the mailbox but seperate (i.e. in the struct
netconn).

> Since it's something which could take time to define, 

Yes, after 1.3.0 I think, and I can't think of any suitable workarounds
before 1.3.0.

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




reply via email to

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