From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15283 invoked by alias); 18 Jun 2007 15:39:43 -0000 Received: (qmail 15276 invoked by uid 22791); 18 Jun 2007 15:39:42 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Jun 2007 15:39:38 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l5IFdaYq030955 for ; Mon, 18 Jun 2007 11:39:36 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5IFdZ7i024382 for ; Mon, 18 Jun 2007 11:39:36 -0400 Received: from localhost.localdomain (vpn-14-225.rdu.redhat.com [10.11.14.225]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l5IFdWI1008133; Mon, 18 Jun 2007 11:39:32 -0400 Message-ID: <4676A722.8050503@redhat.com> Date: Mon, 18 Jun 2007 16:53:00 -0000 From: Adam Jocksch User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: Mike Cvet CC: frysk Subject: Re: New observer interface for SteppingEngine References: <4672EC0B.9050203@redhat.com> <46768C6B.9080609@redhat.com> In-Reply-To: <46768C6B.9080609@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00314.txt.bz2 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.