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

[Frédéric BERNON]

>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.

About mailboxes, I would see three kinds (for me, "dynamic" and "variable" are 
different kinds):
1/ fixed size (you don't provide any size when you create them, the max size is 
defined by build options)
2/ dynamic size (you can provide a max. size when you create them)
3/ variable size (you don't have real max. size, it's a kind of list)

What I suggested is the 2/ (and not the 3/). 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).

>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.

Yes, but choose the limit with an option like proposed in "[task #7421] 
Implement SO_RCVBUF" is also fast to implement (since we already have a 
netconn::recv_avail which count bytes in the netconn::recvmbox, even if it's 
not very well protected)

>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).

It's what it does for netconn::recv_avail and netconn::recvmbox.

  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Jonathan Larmour
Envoyé : mardi 30 octobre 2007 16:06
À : Mailing list for lwIP users
Objet : Re: RE : RE : [lwip-users] managing storage problems.


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


_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf