This will get you started https://gist.github.com/uklance/88c9a5400872273d9b14 On 6 Nov 2014 03:01, "Alex Kotchnev" <akoch...@gmail.com> wrote:
> 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 > > > > > > > > >
