http://blog.gmane.org/gmane.comp.lang.groovy.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19830 There has been a lot of discussion about the issues involved in using SwingBuilder in a multithreaded manner. I've created a small example that shows how to do that in a very simple and correct manner. It's only a small start, and doesn't include explanation of the theory, but may be helpful to some folks. http://docs.codehaus.org/display/GROOVY/Multithreading+with+SwingBuilder Jim --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-12-02T00:38:58 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19829 kris helenek schrieb: this is changed in 1.6 now bye blackdrag Jochen Theodorou 2008-12-01T15:55:28 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19828 Jim White schrieb: [...] you did not fully understand... Let's say I use invokeLater to put C1 on the stack to be executed for the event dispatch thread. And then I use invokeAndWait to push C2on the stack before C1 is processed. That means first C1 will be done and then C2. That in itself is no problem. The problem is that state stack in swingbuilder. if we have frame{edt{panel{}} with {panel{}} being C2, then we would push C2 on the edt stack, but what gets executed first is C1. The result might be, that the UI created by C1 will be part of the frame that should have contained only the UI created by C2. That thread would then have to be the edt itself. Now imagine I am at application startup and I want to show a greeting window with load state information while I am building the complex UIs and load all the needed data. If I would do all that in the edt, then the window would be shown, but never updated till the big UI is done. Also in for example Java1.5 no redraw would happen, meaning that if a part of the GUI was hidden it would appear as gray rectangle then. Later versions may behave the same, depending on how swing is implemented. What you certainly would not see is a status bar showing the loading process or a small text telling the user what it currently does. that is of course just an example, but it hopefully shows the problem when you do it all in the edt. You make the simple error, that you assume that SwingBuilder always runs in the EDT. Nobody does guarantee that unless we check the Thread. What you mean is that you can change a realized UI from the EDT. That is the way it should be done. But that is not "do it all in the EDT" and that is not the multithreading issue with SwingBuilder. Danno tried to make that more easy.. also SwingBuilder itself implies with the edt method that it works across threads, which is not the case. Again, my frame{edt{panel{}}} example... where exactly do you want to synchronized here? A user writing this has multiple problems. First it kind of implies that the panel{} method is executed right after the edt method. But that is not the case, because there might be other elements in that are processed on the EDT first. Next he might assume that the panel is added to the frame.And exactly here comes the real problem, because this implies that the swingbuilder state has not been changed till panel{} is executed. That if two threads do frame{edt{panel{}} at the same time? What state does the swingbuilder have? The result maybe one of: both panels are added correctly, one frame is empty and the other contains both, panel1 for frame1 appears in frame2 and frame1 shows panel2 instead. depends... it is much more easy to get these conflicts using SwingBuilder because in normal swing programming you reference the parents you add components in by name, not implicitly by nesting structure. Why "any"? You can create components in another thread, but adding the component must be done in the edt if the the parent container is realized already. But you can do many things like this. Especially complex GUIs and GUIS with long initialization phases. not "initial construction" as in application startup, but "initial construction" as in "I build a new panel containing my GUI elements", yes. that would be true if Java would be capable of executing only one Thread at the same time if there is only a single core. While the GUI is created this way the user will still be able to press the "cancel" button to abort the GUI creation. bye blackdrag Jochen Theodorou 2008-12-01T14:40:02 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19827 Russel Winder schrieb: Russel, please read again... This was no assumption, this was the logic result of the bug with call site caching that fixed. bye blackdrag Jochen Theodorou 2008-12-01T12:31:07 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19826 [ . . . ] As far as I can tell from the Gant unit tests, this change makes no difference whatsoever to the behaviour. It seems then assumptions and hypotheses are failing to nail this problem. Russel Winder 2008-12-01T10:49:11 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19825 Correct. but what the SB is being used for is to build new widget trees that that have yet to be shown or realized, and then attaching them on the EDT. For example, creating a set of stock price updates when a price is received off the EDT, and then (on the EDT of course) attaching the resulting tree to the frame showing the data. This is why I am against merging edt into build(Closure) for the SwingBuilder. There are instances where one doesn't want the build to happen on the EDT. Merge it in SwingBuilder and you take that choice away from the developer. It's not like some toolkits and environments where there is one and only thread (ajax, flex, I'm looking at you). It's not SwingBuilder that has been made threadsafe, it is the FactoryBuilderSupport that has had it's build context made into ThreadLocals so they can be called in parallel. There are a couple of other builders that use FBS. While SwingBuilder is a large consumer, it is not the only one. When using mutliple builders you also lose context that the other builds may have stored in the builder's context. A builder is a binding and in the build(Script) calls the builder itself is attached as the binding. That's part of it's value. Not entirely. EDT has higher than default priority so its paints happen more reliably. Doing expensive processing in the back end, like processinga 20MB XML fila against a 6MB schema, and generating widgets off of appropriate parts in a highly interactive fashion. Don't laugh, I've actually had to do it in a swing app. And I count my lucky starts I wasn't doing this across HTTP with XSLTs driving the data, they can't handle that scale. ------------------------------------------------------ I'm Danno Ferrin, and I approved this message. Danno Ferrin 2008-12-01T05:02:16 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19824 The edt and static build(Closure) with it's built-in edt call is because Groovy (or any Java) application normally enters the user's code on the main thread. What typically happens is a user builds a Swing tree, shows it, then makes some more Swing calls on it, which is a direct EDT violation. The only opportunity for MT Swing building is prior to it being shown. Once event handlers are being called, it is too late. No. invokeLater and invokeAndWait post an event to the queue and so they are automatically serialized. Any invokeLaters are going to be performed before the edt or invokeAndWait call. If only one thread is permitted to use a SB at a time (which is only sensible - Swing API calls, even when not restricted to the EDT are not threadsafe) then the edt call does nothing special. You can certainly use a SwingBuilder in an event handler because it is dispatched on the EDT (hence the name). What you can't do is any building on a Swing hierarchy that has been "realized" (essentially had either pack() or show() called). This whole notion of making SwingBuilder threadsafe is misguided. Swing components cannot be constructed and initialized via MT without that MT doing it's own synchronization. There is no reason for SwingBuilder to attempt to do it. If a user is going to actually do MT building (which can only be done prior to any Swing component involved being shown or added to any component which is shown) the only thing they can do is the initial construction in which a parent starts building, it's children then build (which is perfectly well done with separate builders, you've got to make separate threads anyhow) and those results are added to the parent when they complete. Of course unless you've got idle cores, all this MT jazz is wasted. If this change is going to be attempted, it needs a JIRA, examples, tests, and documentation. Jim --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-12-01T03:11:58 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19823 If I remember correctly Hans Muller apologized for the change in rules a few months ago. Adding components to a Frame was allowed at first, then became a no-no, then became good practice again. Paul King wrote: Andres Almiray 2008-11-30T19:29:35 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19822 To be more precise, the building part of the builder shouldn't need to concern itself with the thread state. Actually what is in SVN right now is the ThreadLocal verison (your preferred solution from earlier IIRC), which allows for parallel builds. The edt call no longer results in an exception but it brings the build context over to the EDT before calling the clousre. Kinda a clinky form of continuations This will work now, since edt brings over the build context to the EDT thraed. Fourtionaltely no one has tried that yet, delaying a build with explicit concurrency looks to be problematic. Better to reference the desired parent via the container() node in the new thread, that's partly why it's there. Corret, this is a bad assumption. Many complex apps will do this fewquently the edt() call no longer deadlocks, and brings over the state. I think I am missing some context for your comments however... Danno Ferrin 2008-11-30T19:07:09 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19821 Jim White schrieb: [...] if that where the case, then we would not have the edt-thread blah blah we have now. Especially not the "if thread is edt" parts. I might have got it wrong, but imho the current version does only enable the serial usage. It id deadlock if not before, it does print an error message now. The problem might be what "serial" means here. You probably mean that if I have frame{edt{panel{}}}, that the panel becomes part of the frame, since the edt method call should ensure that this happens next. But what if a invokeLater that uses the swing builder is called after frame is entered and the edt closure not yet executed? This is already a threading conflict. We are not so much talking here about the typical multitheading issues you can get, like having destroyed structures, wrong partially overwritten values and usages of uninitalized objects... This is about ensuring that panel in frame{edt{panel{}}} is executed without other swing builder parts changing the state stack. And this is a real problem unles you never use swingbuilder to create something as a reaction to an event or never use invokeLater and so on. And just assuming that this won't be the case is simply wrong. At last it should not be made too easy. but the edt call is exactly that, too easy... too easy for the user to misuse bye blackdrag Jochen Theodorou 2008-11-30T18:55:42 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19820 Right, and build (Closure) has an entirely different semantic than build(Script). Build(script) is a static method and it does not create a new instance of the builder to dispatch the call to. Really, it's use in WingsConsole dosen't add anything benificial to the scripts and should have been removed instead of factored into the build(Closure) method. I should clarify, I meant Java 5.0 when I referenced 1.5. 6.0 doesn't do grey rectangels anymore, just GUI freezes in it's place. Griffon never worked on Groovy 1.5, it depends on ASTTransformations so it could never work on the older version. And yes, in 1.5 SwingBuidlers were not thread safe. All FactoryBuilderSupport builders had the threading bug I encountered. Most of the other threads that store state instance fields and not method variables in the call are similarly not thread safe. This includes ant, cli, DOM, and I stopped lookling at them after that. Sorry, I'm fairly sure backporting AST Transformations to 1.5.7 won't fly. ------------------------------------------------------ I'm Danno Ferrin, and I approved this message. Danno Ferrin 2008-11-30T17:24:29 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19819 Console.run uses build(Script) then the ConsoleView script does several build(Class). In stripping ConsoleView down (I don't need the multiple platform jazz) those build(Class) calls became build(Closure). You make it sound like putting SB.build(Script) onto the EDT causes problems with your code in 1.5. If you're saying that Griffon doesn't work on 1.5 then it sounds like you're starting with threading problems. In particular SwingBuilders are not threadsafe. The root of this problem is that SwingBuilders were fine wrt. MT (which is to say the use must use them serially). You wrote bad MT code in Griffon. You've now moved that same inability to write correct MT code into Groovy. Stop already and go back and make Griffon work properly on Groovy 1.5.7. You need to use threads correctly. Threading may workaround stack corruption bug, but only if you can write safe MT code. SwingBuilders don't need or want to know anything about threading. You've got to stop causing races by reentering objects that require serial access. Undo this bugged MT code you've put into Groovy and fix your own code first. Jim --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-11-30T17:02:36 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19818 There's another fix in head that I feel should satisfy all parties. It is source compatibile with the WingsConsole originally posted, without bringing EDT concerns into build(Script). Had to use some meta-programming to make it work, but that's groovy. --Danno On Sun, Nov 30, 2008 at 8:14 AM, Danno Ferrin <danno.ferrin-uuMoq9TLNRJBDgjK7y7TUQ< at >public.gmane.org>wrote: Danno Ferrin 2008-11-30T17:01:22 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19817 GriffonApplicaitonHelper and some of the genreated code. BTW, where does groovy.ui use build(Closure)? I still can't find it. Slower GUI painting and grey rectangles in 1.5 with the new code running Greet. Sorry, those things don't have stack traces. It also preculeds a developer from building their actions and table models off of the EDT. Table models in particular can take a while if the data is coming from stuff like a databased. That exception trace was removed with the MT safe code since it was merely a deadlock detector. That was in the patch that came across mail. Nope, 1.5.x has the same stack corruption bug that caused me to start down the threading path. If anything we should think about brining the ThreadLocal changes into 1.5.8 (but we should tread carefully with that one IMHO). Danno Ferrin 2008-11-30T15:14:44 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19816 The one that started this whole thread. The console in IFCX Wings. And because Wings depends on GroovyForOpenOffice (Wings is an OpenOffice macro written in Groovy), it is quite important (to me anyhow) that the Groovy in GroovyForOpenOffice not break existing macros. http://www.ifcx.org/ I just did a brief look at some of the Griffon source. It isn't obvious to me where build(Script) is being used. You didn't show the failure you got. Could it be the check code to throw the "you can't do that exception" you've added? Does Griffon work with the 1.5.x SwingBuilder? If so then I vote we just roll SwingBuilder back to the 1.5.x version in 1.6 and defer whatever is going on here until later. Jim Danno Ferrin wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-11-30T14:56:48 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19815 The code you mention breaks Griffon. What program does the change you have done fix? On Sun, Nov 30, 2008 at 4:56 AM, Jim White <jim-3x83HEs+8FyL7B8feK0ILA< at >public.gmane.org> wrote: Danno Ferrin 2008-11-30T14:16:12 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19814 Jesus, not only has he not merged my fix to 1.6, he's reversed it on the trunk again. http://fisheye.codehaus.org/changelog/groovy/?cs=14239 Did you OK that Guillaume? Jim Jim White wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-11-30T11:56:29 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19813 No, not at all excellent. Danno refuses to allow the fix I need to work around his broken code. http://fisheye.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/main/groovy/swing/SwingBuilder.groovy?r1=14227&r2=14229 If you compare 1.6 to trunk you will find they are not the same. If it is still broken when 1.6 is released then I'll just have to fork. What a monster waste of time this is. Jim --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Jim White 2008-11-30T11:37:07 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19812 Excellent, guys :-) On Sun, Nov 30, 2008 at 7:05 AM, Danno Ferrin <danno.ferrin-uuMoq9TLNRJBDgjK7y7TUQ< at >public.gmane.org> wrote: Guillaume Laforge 2008-11-30T09:54:21 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19811 It is good to know that there was a recent change on Subversion trunk that relates to this. The consistency gives me comfort that the problem is soluble -- it may be that the problem is with Gant not with Groovy, but actually I think the problem is with both. I don't think line number reporting is right in Groovy just now and I am becoming more and more convinced that this bit of the Gant unit test code is fundamentally flawed :-) I am loathe to change the Gant unit tests at the minute though until the Groovy issue is sorted since it is the main example of the problem! No it has three lines since there is a newline immediately after the '''. Or perhaps Groovy strips leading and trailing whitespace? If this were the case then it would explain why I get 2 instead of 3 in various other situations. Done. GROOVY-3167. OK, good to know. As noted above I think this bit of code used in the Gant unit tests may be fundamentally flawed, so it may be going away completely soon, to be replaced by something that doesn't have an error in it and so cannot act as a test to see whether things are fixed in Groovy. The question is whether the problem needs sorting for 1.5.x as well as 1.7.x -- for me 1.6.x has the right behaviour already. Russel Winder 2008-11-30T09:17:59 http://permalink.gmane.org/gmane.comp.lang.groovy.devel/19810 Fix has been migrated to 1.6 ------------------------------------------------------ I'm Danno Ferrin, and I approved this message. Danno Ferrin 2008-11-30T06:05:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.groovy.devel