Re: [boost] Review Request: future library (Gaskill version) - Guard question

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2008-04-14 22:14:09

On Mon, 14 Apr 2008 09:58:52 +0200, Kowalke Oliver (QD IT PA AS) wrote:
> where does the code below block? I believe in boost::bind(Add, fa, 3)
> where fa is inplizitly converted to an int - right? So
> JobQueue::schedule is executed only if fa got an value assigned?!
> 
> future<int> fb = q.schedule<int>(boost::bind(Add, fa, 3), fa); // fa + 3

Hi Oliver,
It doesn't block.  This is code from the
"Guards" section of my documentation - the schedule() method is modified
to accept a future<T> as the second argument for use as a guard. 

fa is not implicitly converted to an int (and does not block), because the
second schedule() arg is in the context of a future<int>.

fa is also not implicitly converted to an int within the bind, because the
bind is templated such that it gladly accepts fa as a future<int>
without forcing it into an int context until the function is called. 

The guard magic comes from the change we made to the schedule() method just
before that example - so that the job is not REALLY scheduled until fa
(the guard) is fulfilled (via a callback).

The following code does not dead-lock, for example:

  promise<int> p9;
  future<int> f9(p9);
  future<int> f8 = q.schedule<int>(boost::bind(Add, f9, 3), f9); //no block
  p9.set(99); // we still get here without a deadlock block
  assert(f8.get() == 102);

future/example1.cpp contains all of the example code from the
documentation if you actually want to build it.

The lack of clarity is certainly yet another argument for getting rid of
the implicit conversion method, though.  If no one speaks up in it's
defense soon I'm likely to axe implicit conversion.

-braddock