It seems to me, just from following this thread (and without looking at the code), that there is a problem with invokeAndWait(). If the following 2 assertions are true, then invokeAndWait() is dangerous and should be avoided.
(1) There is, in general, no way to guarantee that the code launched by invokeAndWait() will not perform another call to invokeAndWait(). (2) "Nesting" invokeAndWait() calls in this way causes deadlocks. Assuming my assertions are true, then the only time you can safely call invokeAndWait() is when the launched code is completely owned by you (that is, does not rely on anything other than the Java library), and you can guarantee that for the life of the code that it will never make a nested call (even when someone else is maintaining it). Actually, even then you are not absolutely safe, since the invokeAndWait() implementation could itself initiate a nested call to invokeAndWait() [although that would be a serious bug]. Sam > -----Original Message----- > From: Lolling, Jan [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2003 7:38 AM > To: [EMAIL PROTECTED] > Subject: AW: InvokeAndWait problem > > > hello, > my experience is, that it could be, that invokeAndWait never > come back an than our application hangs. I have not found the > necessary circumstances to reproduce this bug, but > invokeLater avoid a total crash. invokeLater does how it is > called: invoke and do not wait. Your method goes on after > invoking the thread. You have the same theme in Swing. > > Jan > > -----Urspr�ngliche Nachricht----- > Von: Siarhei Biarozkin [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 13. M�rz 2003 16:33 > An: Batik Users; [EMAIL PROTECTED] > Betreff: Re: InvokeAndWait problem > > > Hi, > how about using invokeLater() on the runnable queue ? we see > only minor delay when using invokeLater() instead of > invokeAndWait() Cheers Sergey Beryozkin > ----- Original Message ----- > From: "Harm Cuppens" <[EMAIL PROTECTED]> > To: "'Batik Users'" <[EMAIL PROTECTED]> > Sent: Thursday, March 13, 2003 3:20 PM > Subject: RE: InvokeAndWait problem > > > > Hi, > > > > Thanks for the reply, I see your point, but the problem > will still be > there. > > In the void redo > > > svgCanvas.getUpdateManager().getUpdateRunnableQueue().invokeAndWait(ne > > w > > Runnable() { > > // my code which acts on the DOM > > }); > > } > > > > Batik would still be able to call invokeAndWait in one of it's > > methods. Because my undo/redo code works with the DOM, lots > of events > > are triggered as a result. These events can be for example > in my case: > > DOMNodeInserted, which the Bridge takes care of. In my case > an Image > > element being inserted with an XLink, then the URIResolver calls the > > checkLoadExternalResource(...,...) which calls invokeAndWait again! > > > > Harm > > > > -----Original Message----- > > From: Siarhei Biarozkin [mailto:[EMAIL PROTECTED] > > Sent: donderdag 13 maart 2003 16:12 > > To: Batik Users; [EMAIL PROTECTED] > > Subject: Re: InvokeAndWait problem > > > > > > Hi, > > I'd recommend not to couple your undo/redo functionality with the > > Batik, after all, it's just one component of your application. > > Instead, use something like this : > > > > Undoable undoable = new Undoable() { > > void do() { > > > svgCanvas.getUpdateManager().getUpdateRunnableQueue().invokeAn > dWait(new > > Runnable() { > > // do it/redo it > > }); > > } > > void redo() { > > > > > svgCanvas.getUpdateManager().getUpdateRunnableQueue().invokeAndWait(ne > > w > > Runnable() { > > // undo it > > }); > > } > > } > > > > YourUndoManager.redo() { > > undoable.redo(); > > } > > > > YourUndoManager.do() { > > undoable.do(); > > } > > > > There may be many more, perhaps, better approaches, but the > key is to > > separate concerns Cheers > > Sergey Beryozkin > > > > ----- Original Message ----- > > From: "Harm Cuppens" <[EMAIL PROTECTED]> > > To: "Batik Users (E-mail)" <[EMAIL PROTECTED]> > > Sent: Thursday, March 13, 2003 2:58 PM > > Subject: InvokeAndWait problem > > > > > > > Hello all, > > > > > > I'm adding undo/redo support to my application (a little > SVGEditor). > > > I > > have > > > a JSVGCanvas where I can draw my lines, rectangles etc. I can also > import > > > images (or reference them) into the SVG document. > > > > > > For every action I perform I added undo/redo support. > > > For the undo/redo action to happen immediately on the > canvas, i call > > > the InvokeAndWait method: > > > > > > > svgCanvas.getUpdateManager().getUpdateRunnableQueue().invokeAndWait( > > > new > > > Runnable() { undoManager.redo() }); > > > > > > But I have the following problem, I insert an <image> > with a xlink > > > to a > > file > > > on my disk into the document. I then undo this operation (so the > > > image > is > > > removed again). Now when I try to redo this action, I call the > > InvokeAndWait > > > method (to get immediate results on the canvas) which starts the > > > redo > > code. > > > But it seems that the class org.apache.batik.bridge.URIResolver > > > calls > the > > > method userAgent.checkLoadExternalResource(purl, pDocURL). This > > > brings > me > > > to the code inside the BridgeUserAgentWrapper inner class of > JSVGComponent > > > where the method calls another InvokeAndWait resulting a > total halt > > > of > the > > > program. So I'm in a situation where i'm calling invokeAndWait to > > > run > code > > > that could call invokeAndWait again :-( > > > I have tried the invokeLater method, but that gave the > same results, > > program > > > just hangs. > > > > > > Is there any way to get arround this (besides not using > > > invokeAndWait)? > I > > > really like to have my undo/redo actions to occur immediately > > > without > > having > > > to worry about that code calling another invokeAndWait. > > > > > > Thanks, > > > > > > Harm > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > 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] > > > > > > > > > --------------------------------------------------------------------- > 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]
