Thago & Lance - thanks a lot for your detailed comments and ideas. On to the details :
The issue that I ran into with passing page instance variables into threads is at http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Page-instance-variables-and-threads-td5728565.html . The specific issue is that the page instance variable is just a "facade" to the state that is stored in the thread local - while I'm accessing it inside a page method (same thread), I can access the value. When I access the same variable inside the new thread, it's value is null, as the new thread doesn't inherit the thread locals of its parent thread. Lance - any chance you could throw you example component into a GitHub gist for me to see ? In terms of being able to pass the state to the child threads, I was thinking - is there a way to put this state into InheritableThreadLocals (instead of ThreadLocals) so that child threads have access to the thread local state. Granted, it seems that with InheritableThreadLocals, if any state changes in the child thread it will not propagated to its parent, but that might be OK. Cheers - Alex K On Wed, Nov 5, 2014 at 6:34 PM, Lance Java <lance.j...@googlemail.com> wrote: > FYI I've worked out a very simple / no frills way to do this. > > <t:parallel> > <t:someComponent /> > </t:parallel> > > The parallel component would then render it's ComponentResources.getBody() > in a separate thread (note that the body Block can be TypeCoerced to > RenderCommand). > > As Thiago discussed, his shell element concept could be achieved by passing > an empty RenderQueue and MarkupWriter to the body RenderCommand (which is > rendering asynchronously to the main request). Once the async render > finishes, the resultant markup String could be introduced into the main DOM > on the request thread. > > Note that request / response will be null on the async thread. Any request > scoped property bindings and Environmentals will also be null. > PerthreadManager.cleanupThread() should be called after the async render. > On 5 Nov 2014 16:51, "Thiago H de Paula Figueiredo" <thiag...@gmail.com> > wrote: > > > Hello, Alex! > > > > On Tue, 04 Nov 2014 21:23:10 -0200, Alex Kotchnev <akoch...@gmail.com> > > wrote: > > > > I'm a bit puzzled by the negative vibe that I'm getting. Just to be > clear > >> - > >> > > > > I'm not perceiving any negative vibe, just one idea being proposed and > > some people thinking that it wouldn't actually reach its objective > (making > > page rendering faster). > > > > I'm not asking anyone to do any work on my behalf, or to drop everything > >> and work on this as if it's the most important thing in the world (which > >> it is not). I'm also not here to troll and say "tapestry sucks, this > other > >> framework is better" > >> > > > > I don't think anyone here is thinking that. I definitely am not. :) > > > > - nothing of the sort (in my first email I did > > > >> explicitly mention that after evaluating the two for a while I did find > >> Tapestry to be superior and I'm still sticking with it). I saw this > >> approach in a different framework, I found it interesting and I'm > curious > >> for input from the more knowledgeable people on this list on how one > >> might tackle this. > >> > > > > I actually think it's doable without a thread-safe DOM, but with some > > limitations, even if I think it's not worth the effort: > > 1) The component would need to generate a DOM element immediately, let's > > call it shell element, before spawning a new thread. This way, the new > > thread would only work inside this shell element, avoiding the need of > > synchronizing the whole DOM tree (Document instance). This could be > > implemented with a new render phase event. > > 2) The component should avoid changing DOM elements it didn't create > > (a.k.a DOM rewriting), just creating new elements inside this shell > element. > > 3) The component couldn't be in a loop (Loop or Grid), as the same > > component instance is rendered many times. > > 4) The developer must know that things may go wrong in unexpected ways. > > > > likely be much faster than actually getting the data. The trouble is > that > >> I did try the approach of "firing up new threads to do the work", but > then > >> I ran into issues w/ Tapestry's thread local data not being available in > >> those other threads when I pass in the variables from my tapestry > >> page/component ( I posted in a different thread a few weeks ago about > >> that). > >> > > > > This is weird. If you don't pass the component, page or mixin objects > > themselves to this other threads, there shouldn't be any problem. Could > you > > link to the thread please? > > > > @Lance - thanks for pointing out the fact about the mutability of the > DOM > >> - AFAIK, Lift snippets are indeed "transformations" of the DOM that they > >> manipulate, and from the POV of how Scala deals w/ XML the DOM is > treated > >> as an immutable structure that goes through a bunch of transformations. > >> So, this might be a critical distinction that I missed in my initial > thought > >> process. > >> > > > > Lift is a Scala framework. Scala favors immutable structures, so this > > difference between Lift and Tapestry isn't unexpected to me. > > > > Anyway, the argument here seems to me like the argument for parallel > >> collections (when I first saw them in Groovy for example). My initial > >> reaction when I saw them for the first time was "why the heck would I > >> want to do this, of course I'd want to go over my collection items one > by > >> one". > >> > > > > Actually, in some cases, the parallelized version is slower than the > > sequential one due to threading overhead. > > > > -- > > Thiago H. de Paula Figueiredo > > Tapestry, Java and Hibernate consultant and developer > > http://machina.com.br > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
