New observer interface for SteppingEngine

New observer interface for SteppingEngine

[Adam Jocksch]

After some discussion with Tim and Mike, it's been generally agreed that 
the interface for observing the stepping engine needs to be improved 
beyond what's offered by the default Java Observer/Observable interface.

Looking at SteppingEngine.SteppingObserver, it looks like we need the 
following methods:
 - updateTaskStopped(Task)
 - updateNotStopped()  <-- probably taking a task as a parameter? (or 
maybe a list of tasks)
 - any others?

A few aspects of the current functionality are a little unclear to me at 
the moment, for example when notifyStopped() should be called and not 
notifyTask(Task).

Thoughts?

Adam

Re: New observer interface for SteppingEngine

[Mike Cvet]

Adam Jocksch wrote:
> After some discussion with Tim and Mike, it's been generally agreed 
> that the interface for observing the stepping engine needs to be 
> improved beyond what's offered by the default Java Observer/Observable 
> interface.

I'm still not entirely clear on the limitations here, I only caught 
pieces of it last week - could you describe again the problems you're 
facing?

>
> Looking at SteppingEngine.SteppingObserver, it looks like we need the 
> following methods:
> - updateTaskStopped(Task)
> - updateNotStopped()  <-- probably taking a task as a parameter? (or 
> maybe a list of tasks)
> - any others?
>
> A few aspects of the current functionality are a little unclear to me 
> at the moment, for example when notifyStopped() should be called and 
> not notifyTask(Task).
The two methods notifyStopped() and notifyTask(Task) are leftovers from 
one of the many refactorings of the class, and should be removed. The 
class contains methods similar to what you've described - 
notifyNotBlocked() and updateExecuted(). When performing an operation 
which will leave the requested Task or list of Tasks in a pseudo-running 
state, notifyNotBlocked() tells the observers not to perform any 
operations on the running Tasks. When each of the Tasks becomes 
re-blocked, they pass through updateExecuted, which then calls 
notifyObservers(Task) with the newly stopped Task.

If you need to find out if a particular Task or Proc is 'running' (which 
really means "not stopped"), then isProcRunning(LinkedList tasks) and 
isTaskRunning (Task task) are available.

- Mike

Re: New observer interface for SteppingEngine

[Adam Jocksch]

Mike Cvet wrote:
> Adam Jocksch wrote:
>> After some discussion with Tim and Mike, it's been generally agreed 
>> that the interface for observing the stepping engine needs to be 
>> improved beyond what's offered by the default Java 
>> Observer/Observable interface.
>
> I'm still not entirely clear on the limitations here, I only caught 
> pieces of it last week - could you describe again the problems you're 
> facing?
>
>>
>> Looking at SteppingEngine.SteppingObserver, it looks like we need the 
>> following methods:
>> - updateTaskStopped(Task)
>> - updateNotStopped()  <-- probably taking a task as a parameter? (or 
>> maybe a list of tasks)
>> - any others?
>>
>> A few aspects of the current functionality are a little unclear to me 
>> at the moment, for example when notifyStopped() should be called and 
>> not notifyTask(Task).
> The two methods notifyStopped() and notifyTask(Task) are leftovers 
> from one of the many refactorings of the class, and should be removed. 
> The class contains methods similar to what you've described - 
> notifyNotBlocked() and updateExecuted(). When performing an operation 
> which will leave the requested Task or list of Tasks in a 
> pseudo-running state, notifyNotBlocked() tells the observers not to 
> perform any operations on the running Tasks. When each of the Tasks 
> becomes re-blocked, they pass through updateExecuted, which then calls 
> notifyObservers(Task) with the newly stopped Task.
>
> If you need to find out if a particular Task or Proc is 'running' 
> (which really means "not stopped"), then isProcRunning(LinkedList 
> tasks) and isTaskRunning (Task task) are available.
>
> - Mike
>
>
The problem is that the default Java observer interface doesn't include 
much information as to the type of message received. Having a custom 
interface will not add any extra overhead and it just seems cleaner; the 
messages for tasks running and tasks stopping are completely distinct. 
One of the issues I ran into with my code is that I wasn't sure how to 
tell why the update method was being called. With a custom observer 
interface it would be practically self-documenting. It also seems a 
little strange to have to poll all the tasks that we're interested in to 
see if they're stopped whenever we receive an event via notifyNotBlocked 
when this information could probably be send along with the message.

Re: New observer interface for SteppingEngine

[Mike Cvet]

Adam Jocksch wrote:
> The problem is that the default Java observer interface doesn't 
> include much information as to the type of message received. Having a 
> custom interface will not add any extra overhead and it just seems 
> cleaner; the messages for tasks running and tasks stopping are 
> completely distinct. One of the issues I ran into with my code is that 
> I wasn't sure how to tell why the update method was being called. 

There's certainly nothing I could argue with here - the updates from the 
Java Observables aren't explicit - the Observer must make assumptions 
about what is coming through. But there are really only two cases of 
interest - the Task is stopped (do work), and the Task is not stopped 
(don't do any work). A null parameter for the former, and a Task 
parameter for the latter. I suppose you could compare it to a kind of 
toggle. I'm not sure what other kinds of messages would have to be 
passed through though?

> With a custom observer interface it would be practically 
> self-documenting. It also seems a little strange to have to poll all 
> the tasks that we're interested in to see if they're stopped whenever 
> we receive an event via notifyNotBlocked when this information could 
> probably be send along with the message.
You're right, when the Register/Memory/Disassembly windows become 
multithread-aware, something like that might be required.

What if, instead of re-writing everything, the SteppingEngine passes a 
reference to a frysk.rt.TaskStepEngine through as an argument - which 
contains the Task in question, its current State, and other useful 
things like its Dwfl Object?

- Mike

Re: New observer interface for SteppingEngine

[Adam Jocksch]

Mike Cvet wrote:
>
> What if, instead of re-writing everything, the SteppingEngine passes a 
> reference to a frysk.rt.TaskStepEngine through as an argument - which 
> contains the Task in question, its current State, and other useful 
> things like its Dwfl Object?
>
> - Mike
As an interim solution until thread-awareness becomes an issue that 
sounds like an okay solution. I'll also suggest some more explicit 
documentation for SteppingEngine.addObserver to clarify the assumptions 
being made to other people who may have to become acquainted with the 
SteppingEngine :)

Adam

Re: New observer interface for SteppingEngine

[Mike Cvet]

Adam Jocksch wrote:
> Mike Cvet wrote:
>>
>> What if, instead of re-writing everything, the SteppingEngine passes 
>> a reference to a frysk.rt.TaskStepEngine through as an argument - 
>> which contains the Task in question, its current State, and other 
>> useful things like its Dwfl Object?
>>
>> - Mike
> As an interim solution until thread-awareness becomes an issue that 
> sounds like an okay solution. I'll also suggest some more explicit 
> documentation for SteppingEngine.addObserver to clarify the 
> assumptions being made to other people who may have to become 
> acquainted with the SteppingEngine :)

Fair enough =). I think that this might solve our multithreaded issues 
as well though - since any Task which has a state change (blocked, or 
unblocked) will have its TaskStepEngine passed through, we'll know what 
transition it has made.

- Mike