Task.isDestroyed removed

Task.isDestroyed removed

[Andrew Cagney]

FYI,

I've removed the method:
    boolean frysk.proc.Task.isDestroyed()
Re-running the test-suite showed no regressions, but looking at the code 
leaves me wondering if the callers - frysk.rt.SteppingEngine and 
frysk.proc.ProcBlockAction - have a latent race so I'll explain the issue.

The underlying problem here is the race between adding an observer to a 
task, and having that task die.

First lets examine the two most common cases - where things work.  For 
the first:

-> a task dies and is removed
-> client gets Proc's Task list - contains no dead tasks
-> client adds observer to all Tasks

there is no race as the client doesn't even see the dead Task.  
Similarly, if the task dies after the client's observers have been added:

-> client gets Proc's Task list - contains no dead tasks
-> clent adds observers to all Tasks
-> Task dies and is destroyed, client notified via its installed 
termination observer

there is again no race as the observers have been successfully added; 
and presumably the client is now tracking task destruction using the 
termination observer notification.

That just leaves the race, which is being worked around using the sequence:

-> client gets Proc's Tasks
-> Task is destroyed
-> client checks !Task.isDestroyed()
-> client adds observers to Task

but this also fails vis:

-> client gets Proc's Tasks
-> client checks !Task.isDestroyed()
-> Task is destroyed
-> client adds observers to [dead] Task

The correct way to handle this is to instead always send the request to 
the core:

-> client get's Proc's Tasks
-> client adds observers to Tasks
-> core notifies client of success/fail allowing client to prune list 
using methods:
    .addFailed(...)
    .addedTo(...)
Since the core serializes events and requests, it correctly resolves 
these races.

Andrew