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
[EMAIL PROTECTED]
http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
--------
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
