On Thu, 06 Nov 2014 00:58:51 -0200, Alex Kotchnev <akoch...@gmail.com>
wrote:
Thago & Lance - thanks a lot for your detailed comments and ideas.
;)
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Page-instance-variables-and-threads-td5728565.html
In your case, this may be a Scala-Java behavior expectation mismatch. If
you wrote the exact same logic in Java, your closure would be a anonymous
inner class, non-static. This means instances of the closure have an have
an implicit reference to the surrounding object, which is the Tapestry
page, which right now cannot be shared among threads, resulting on what
you're experiencing. So you're not passing just the field value to the
closure: you're passing the whole page object.
As Lance said, if you created a final variable copying the value of the
field, it would work. Here's an example, but be warned I've never
programmed in Scala:
class ShowServer {
@PageActivationContext @Property
var sn:String = _
def setupRender():Unit = {
val string = sn
val servDetFut = for {
jg <- future { mgr.jarGroupName(string)}
props = mgr.props(string)
pl <- future { mgr.players(string) }
worlds <- future { mgr.listWorlds(string)}
ops <- future { mgr.ops(string) }
wl <- future { mgr.whitelist(string)}
bl <- future { mgr.blacklist(string) }
} yield McServerDetails(
server = mcServer,
jarGroup = jg,
worlds = worlds.toArray,
players = pl.toArray,
ops = ops.toArray,
whiteList = wl.toArray,
blackListed = bl,
props = props
)
}
serverDetails = Await.result(servDetFut, 60.seconds)
}
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.
This seems to be a very good idea. I'm not familiar with
InheritableThreadLocal. What could be the downsides of using it instead of
ThreadLocal? Performance? If yes, what would be the overhead? Anyway, we
could create an annotation to force a page instance to use
InheritableThreadLocal instead of ThreadLocal, which would remain the
default.
--
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
