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?
I agree that this is a potentially serious issue, however I have not seen widespread
crashes in hash map, 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) .
Did you replace _all_ instances of HashMap/HashTable? No offence, doesn't thatI'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.
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
