Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On Wed, May 28, 2014 at 09:50:21AM +0530, Jassi Brar wrote:
> On Wed, May 21, 2014 at 10:57 PM, Mark Brown <broonie@kernel.org> wrote:

> >> +     if (!cl->tx_tout) /* wait for ever */
> >> +             cl->tx_tout = msecs_to_jiffies(3600000);
> >> +     else
> >> +             cl->tx_tout = msecs_to_jiffies(cl->tx_tout);

> > Is the default wait for ever the best timeout - I'm not sure it's best
> > from a defensiveness point of view.  It should be fine either way,
> > it's just a matter of taste.

> The client wants the call to be blocking. Out of 'zero', 'infinity'
> and some 'valid' delay, it makes better sense to have 'infinity' than
> zero or another value that might be valid for some platform. I assume
> 1hr to be 'infinity', though I am open to better suggestions. Maybe
> put a WARN() ?

I think my inclination would be to have the client required to specify
what it thinks is a sensible delay and complain loudly if nothing is
specified.  Having zero default to wait for ever (as opposed to
something like a negative number) means that if someone memset()s the
struct (as people tend to) then if things go wrong the system will tend
to run into long timeouts which tend to give an unpleasant experience if
things go wrong.  

Forcing the user to think what a sensible delay is seems likely to
ensure that sensible values are picked rather than people not thinking
about it at all since if everything is working well and messages get
answers it's OK.

Sorry about the delay in replying here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]