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

[Jonathan Larmour]

Frédéric BERNON wrote:
>> 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.
> 
> [snip]
> Have a netconn::mbox with
> the same size that netconn::recvmbox doesn't seem useful. I think that
> adding a size parameter to sys_mbox_new is a good solution (like we have
> add the stacksize to sys_thread_new). If your OS doesn't support that,
> you don't have to use it. Since there is no lot of sys_mbox_new calls (I
> count 8 in cvs head), and since these calls are not on critical paths
> (send/recv calls), I stay in flavor to change it (after 1.3.0).

Don't get me wrong - I agree. I was just saying that whatever the solution
is, it cannot absolutely rely on requesting a mailbox of size X really
giving you a mailbox of size exactly X.

(By the way, you mean favor, not flavor which is quite a different word :-)).

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