This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Forward of blocked observer discussion


Hi Andrew,

On Thu, 2006-10-12 at 17:38 -0400, Andrew Cagney wrote:
> >      /**
> > If <code>Action.CONTINUE</code> is returned or after
> > +     * <code>requestUnblock()</code> is called on the Task the
> > +     * observer is removed from the task and will not be triggered
> > +     * unless it is explictily readded. To continiously monitor a
> > +     * running Task see the <code>Instruction</code> interface.
> > +     */
> This adds an obscure side effect to Action.CONTINUE, is inconsistent 
> with every other observer, and is redundant.   Any observer, not just a 
> blocking observer, needing to both unblock and remove itself can just 
> request its removal.

Yes. But if you think that is confusing we can just hold the task till
it is explicitly deleted. The only issue is that with a Blocking
observer it is unclear what the difference between Action.CONTINUE and
Action.BLOCK is. We can just decide there isn't a difference for
Blocked.

>   The state machine needs to then directly handle 
> that, but as npremji recently discovered, and is now working on, it 
> isn't reliable.

What isn't reliable?

> Also remember, as you/I previously discussed, and similarly I sami and 
> adam discussed, the blocking and instruction observers have too much 
> functional overlap, making one redundant.

At our last meeting we discussed adding two separate observers. Since it
was thought that adding a task blocking observer would be easier to add
first and that we could then add a stepping instruction observer next.
And because they are slightly different/have different roles.

As it turned out the most work was actually adapting the TaskState
machine and the way you add a TaskObservation to make it easy to request
a temporary suspend from the Task to change any aspects of the Task. Now
adding any observer that (temporarily) suspends, whatever its semantics
should be easy.

> BTW, Sami/Adam preferred to 
> see the observer called something like Blocking rather than Instruction 
> as that better reflected its behavior.

The Instruction observer (for which I just committed a first version) is
different from a Blocking observer. The Instruction observer gives
updates whenever a Task executes an instruction. The Blocked observer
would give an update as soon as the Task is suspended (or immediately
when the Task is already blocked).

Note that for reliably knowing whether a Task is suspended or not the
Instruction observer alone isn't enough since it won't trigger if the
Task is already blocked.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]