On Mon, 2007-11-05 at 15:37 +0000, Andrew Stitcher wrote:
> On Mon, 2007-11-05 at 10:26 -0500, Alan Conway wrote:
> > I want to add a timeout to the public API (I'm adding "get" style
> > subscription as an alternative to "listen" style)
> >
> > Opinions, should I:
> > a) use qpid::sys::Duration as the timeout parameter?
> > b) use uint64_t nanosecond value?
> > c) do something else...
>
> c) I think it's usually better to specify timeouts in terms of an
> absolute "wait until" time (I know this isn't the common practice).
>
> The reason is that the if waiting gets interrupted for some reason other
> than timeout or completion (signal for instance) then all you need to do
> to carry on is the same operation again. I suppose I'm saying this
> operation is idempotent.
That is true for low-level condition waits because you need to be able
to capture the lock to check for 'false wakeup' but I don't see the
benefit in a user API. Can you illustrate what you have in mind?
I'm thinking of something along the lines of
bool get(Message&, Timeout); // return false if we timed out.
So the user would say:
if (get(msg, 10secs)) { handle(msg); } else { handle timeout }
What are you proposing?
while (get(msg, now+10secs) { what? }
Why would we ever return other than the two defined outcomes: got a
message/did not get a message? How would the user detect that we are in
this third state? And what could they usefully do about it?
> If you specify a duration then you need to calculate the absolute
> waiting time internally to do this, or return the remaining time like
> the Linux select does.
Agreed - but why would we impose that on the user? What additional
flexibility would they gain?
Cheers,
Alan.
