>> I have a question regarding the mbox:es. >> We have very short on memory in our system, so we want to have >> the queue length in the mbox set as low as possible.
>> This however results that we sometimes gets mbox errors due to >> that the mbox queue is full. >> So my question is what happens when the mbox is full, will lwip >> retry again later or will it result in forever lost message?>
> >It will depend on your ports. >On unix port in contrib directory. sys_mbox_post will wait forever >until there is space in the mbox.
The implementation of sys_mbox_post in my port will also wait forever.
However the sys_mbox_post is only used a few times in the lwip-stack. The sys_mbox_trypost is more widely used and that function will not wait forever, it will return ERR_MEM if the mbox is full. So my question is what will happen to those messages? Will they be
lost forever or will the lwip-stack retry again later?
I'd rather not change the lwip stack code. But perhaps it is possible to replace all calls to sys_mbox_trypost with sys_mbox_post instead? I however have no idea what impact that would have on the stack, but
maybe Kieran or Simon has a clue on that impact?
>> Is there a way to know how many mbox:es that will be created in >> the system? >> >See SYS_MBOX_SIZE
No, if I understood it correctly the SYS_MBOX_SIZE is not the amount
of mbox:es created, it's how many messages each mbox can hold. So the question remains, can I know how many mbox:es that the lwip- stack will create in my system? Does it depend on how many connections that I have in the system?