qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: API question
Date Mon, 05 Nov 2007 16:40:08 GMT
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?


View raw message