In my email a few minutes ago, I mentioned that the
scheduleGVTRendering() can get called rapidly and wildly if someone is
dragging the corner of a window... I solved this problem by the
following addition to JGVTComponent constructor:
addComponentListener(new ComponentAdapter() {
public void componentResized(ComponentEvent e) {
if (updateRenderingTransform()) {
if (scheduledResize != null) {
try { scheduledResize.interrupt(); }
catch (NullPointerException ex) {}
}
(scheduledResize = new Thread() {
public void run() {
try {
Thread.sleep(250);
scheduleGVTRendering();
}
catch (InterruptedException ex) {}
finally {
scheduledResize = null;
}
}
}).start();
}
}
});
...... instead of:
addComponentListener(new ComponentAdapter() {
public void componentResized(ComponentEvent e) {
if (updateRenderingTransform())
scheduleGVTRendering();
}
});
On Tue, 2003-06-17 at 09:12, Brian Modra wrote:
> Hi Thomas,
> thanks for your reply.
> My replies are in-line below...
> Brian
>
> On Mon, 2003-06-16 at 20:58, Thomas DeWeese wrote:
> > Hi Brian,
> >
> > Brian Modra wrote:
> >
> > >Batik crashes when updating due to concurrent modification exceptions
> > >in Sun's HashMap class. Rather than describe this in detail (it happens
> > >in a number of different sequences of events) I think its enough to say
> > >that the exceptions are thrown as a result of AWT thread doing a resize,
> > >at the same time as batik's queue is processing something queued by
> > >invokeLater. Both threads cause an SVG document update, which sometimes
> > >causes the concurrent modification exception in the hash map.
> > >
> > This is very interesting, first a few question:
> > What version of Batik are you working with?
> > What hash map?
>
> batik-src-1.5beta5.zip
> j2sdk-1_4_1_02-fcs-linux-i586.rpm
>
> - I did a gloabal search and replace of "HashTable" and import
> org.apache.batik.dom.util.HashTable - with my HashMap class.
> - I modified org.apache.batik.dom.util.HashTableStack class to use my
> HashMap.
> - Then I did a global search and replace of "import java.util.HashMap;"
> with mine, and took all the "import java.util.*:" apart and did explicit
> imports of all the classes needed.
>
> >
> > I agree that this is a potentially serious issue, however I have not
> > seen widespread
> > crashes in hash map,
>
> Sun's HashMap isn't buggy, its not thread safe (I think they make no
> claims to it being thread safe.) If you use a library class which isn't
> thread safe, in a threaded environment - the only safe way is to wrap
> each call:
> synchronized (blah) { hashmap.whatever(...) .. }
> ... which then gives rise to a very good chance of thread contention
> blockages.
>
> > although I don't generally resize the document
> > heavily (I don't use
> > an 'opaque' resize window manager for example). I'm especially
> > concerned about this
> > as generally synchronization in Batik is not done through thread safe
> > classes etc, but by
> > using thread level/Runnables synchronization. So your suggestion is
> > likely masking the
> > real issue: someone doing something in an improper thread (like
> > modifying AWT from the
> > Update thread or the DOM from the AWT thread) .
>
> You are right... but with these fixes, it does not crash.
> In such a complex system, there will be situations you didn't expect.
> I'd rather that in such a situation, it does not crash completely.
>
>
> The problem occurs when my software is calling invokeLater()
>
> which I get to by calling in this order:
>
> JSVGComponent.getUpdateManager()
> UpdateManager.getUpdateRunnableQueue()
> RunnableQueue.invokeLater()
>
> ... and at the same time a panel resize causes
> JGVTComponent.scheduleGVTRendering() to get called...
>
> I will look into this logic, and set up this call so that the update
> queued up, and only the latest one happens (after a delay of, say, 1/4
> second). The bug may have been caused by multiple calls to
> scheduleGVTRendering() in fast succession when dragging the window
> corner.
>
> > >I've come across this type of problem before in other applications: its
> > >due to Sun's HashMap not being thread safe. I looked at the problem and
> > >decided that it would not take much effort to write a new HashMap class
> > >which was just as fast, and also thread safe.
> > >
> > >My new HashMap is fast, and its only synchronised where it absolutely
> > >needs to be. It is completely thread safe - no concurrent modification
> > >problems, and no blocking thread contentions.
> > >
> > >I've modifying my copy of Batic sources so that it uses my HashMap
> > >rather than any other HashMap or HashTable classes (Suns's or Batik's).
> > >With the new HashMap class, the contentions go away, and I think this
> > >results in a MUCH more stable SVG renderer.
> > >
> > >
> > Did you replace _all_ instances of HashMap/HashTable? No offence,
> > doesn't that
> > strike you as a band-aid approach? For this to be the 'correct' answer
> > one would
> > have to believe that HashMaps are the only concurrency issue in all of
> > Batik. I would
> > really be much more interested in finding out what is causing the
> > concurrent accesses
> > than attempting to make everything multi-thread safe, which is the road
> > you are headed
> > down.
> >
> > >Can I put these changes in to Batik's source code? Who should I talk to?
> > >
> > Vincent usually handles large contributions, but I'm not sure we are
> > there yet.
>
> I'm glad to talk this through some more.
>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
