Re: New observer interface for SteppingEngine

[Mike Cvet <mcvet at redhat dot com>]

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