[kepler-dev] Deadlock while wrapping up

[xiaowen]

Hi Christopher,


Thanks for the explanation.  It does sound like a lot of work.

Is there a way for people with anonymous CVS access to generate the
patches ourselves against 4.0.1?

This would be some sort of middle ground.  We are provided with patches,
but with the caveat that they are not fully tested.  So that the onus is
upon us to test them before we release them further.  If we go this
route, you could gain a whole host of bug testers. :)

I think new features probably belong properly in the CVS development
HEAD, and don't need to be backported.  I'm just concerned about bugs
that would be nice to see fixed in the stable version.


Thanks!
Xiaowen


Am Dienstag, den 21.12.2004, 15:17 -0800 schrieb Christopher Brooks:
> In the past we've provided patches for other packages, but 
> there are several issues.
> - There are the following binaries that need to be updated and
> tested 
>   - source tar with Windows line endings
>   - source tar with Unix line endings
>   - Web Start
>   - Windows installer with Java  
>   - Windows installer without Java  
>   - Experimental installers for Linux, MacOSX and Generic Unix
> 
> The problem is that it takes all day to generate these binaries
> and smoke test them.  Realistically, it takes two weeks to do
> a good job and get something shipped, providing that the
> changes are minor.
> 
> - We've found that trying to ship patches for new features seems to
> involve updating most of the tree.  And then, there are bugs, so we
> need to turn the crank again and generate a new patch.  Simple bugs
> like this deadlock are not likely to involve lots of files though.
> 
> 
> I've been considering setting up way to automatically create known
> good snapshots, but have not gotten around to it.
> 
> The current set of unreleased patches in the 4.0.1 release branch is
> fairly small.  This bug is not that common, we've had two reports in
> 18 months.  Presumably, it has been happening more often and people
> have not been reporting it.
> 
> My current guess is that the next full Ptolemy II release will
> be around May, 2005.  We might do an interim release of Hyvisual
> (CT and DE only) before then.
> 
> Anyway, I'll chew on this some more and get back to you on it.
> 
> _Christopher
> 
> 
> --------
> 
>     Hi Christopher,
>     
>     
>     Does Ptolemy II release patches against 4.0.1 so that users of the
>     latest stable release can also benefit from the bug fixes?
>     
>     Most users of SPA/Kepler don't have Ptolemy CVS accounts, and many/most
>     of them probably prefer to stick with the latest stable release anyway.
>     I'm wondering what the best way is for SPA/Kepler developers to
>     distribute workflows.  Must we also send users instructions for how to
>     patch Ptolemy?
>     
>     
>     Thanks!
>     Xiaowen
>     
>     
>     Am Dienstag, den 21.12.2004, 08:40 -0800 schrieb Christopher Brooks:
>     > Hi Xiaowen,
>     > 
>     > Thanks for including the stack traces of the threads.
>     > 
>     > In ptolemy/actor/lib/ModelFrame.java, executionFinished is 
>     > synchronized.
>     > 
>     >     /** Report that execution of the model has finished.
>     >      *  @param manager The manager calling this method.
>     >      */
>     >     public synchronized void executionFinished(Manager manager) {
>     >         report("execution finished.");
>     >     }
>     > 
>     > It is the only synchronized method in ModelFrame or RunTableau.
>     > It has been synchronized since version 1.1 of ModelFrame in 28-Nov-99.
>     > 
>     > Xiaojun reported a similar bug on May 20, 2003:
>     > 
>     > > The deadlock may appear when:
>     > > the run window of a model loses focus while the model is running,
>     > > then regains focus (because of user action) at the time the
>     > > execution finishes.
>     > >
>     > > The deadlock is between the following threads: the manager thread,
>     > > in updating the status bar at the bottom of the run window, and
>     > > the AWT thread, in repainting the run window.
>     > >
>     > > From the stack trace [...], the manager thread has a
>     > > lock on the run window because the ModelFrame.executionFinished()
>     > > method is synchronized. Other methods in ModelFrame, e.g.
>     > > executionError(), managerStateChanged(), are not synchronized.
>     > > Why?
>     > 
>     > I've gone ahead and made executionFinished() unsynchronized.
>     > 
>     > _Christopher
>     
>     _______________________________________________
>     kepler-dev mailing list
>     kepler-dev at ecoinformatics.org
>     http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
> --------
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev