AW: [lwip-users] Optimistic error handling in lwIP

[Zschocke, Florian]

Kieran Mansley wrote on Donnerstag, 27. Februar 2003 14:52:

> (and I much prefer having an non-void function or
> error code argument rather than using the errno variable).

I would agree that it is preferrable to replace a void function with one
returning an error code. But that may not work with functions which already
have a meaningful return value, like sys_arch_mbox_fetch(). If by error code
argument you meant to pass an error code via a cbr parameter, then I would
disagree since this tends to clutter the code.

> If it gets interrupted, should
> sys_arch_mbox_fetch not just try again?  If we checked the
> result of sys_mbox_fetch to check if it was NULL, all it would
> do as a result is call sys_mbox_fetch again and hope it
> succeeded the second time.  

It may be a question of policy or personal preference but I would say that
sys_mbox_fetch() may not be able to know how to react correctly to a given
event/error. It is a mere wrapper for sys_arch_mbox_fetch() to drive the
lwIP timers. I think it should be up to the application to handle the case
that a message could not be fetched. If it decides to call sys_mbox_fetch()
again, it may do so. Or in this specific case, it may decide to call
recvfrom() again since the error situation should be propagated up to the
application level. 

In our specfic case it may happen that the mbox the fetch() is waiting on
does not exist anymore. This happens during a reset of the project
responsible for the tcpip thread. This means that sys_mbox_fetch() would try
to fetch on a mailbox that is not present anymore. It can't know how to
handle this situation, but the application can.

Florian.