From: marc f. <mar...@jb...> - 2003-01-16 20:22:31
|
hmmm I thought we had cleared the questions of pools of anything long time ago, meaning that modern VMs take care of that. Also bill, you and I have been badly burnt in the past by state management in reused components. My question would then be 'why would threads be different'?. The usual reason is that people say "you want to limit how many threads a process creates, but that can be achieved by just monitoring the number of new threads created by the pool and listening for notifications on thread garbage collection calls. That says that you have pools who just limit the number of threads out there and block for other but associate a new thread for new invocations. marcf > -----Original Message----- > From: jbo...@li... > [mailto:jbo...@li...] On > Behalf Of Bill Burke > Sent: Thursday, January 16, 2003 2:18 PM > To: jbo...@li... > Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken > > > "Each thread holds an implicit reference to its copy of a > thread-local variable as long as the thread is alive and the > ThreadLocal instance is accessible; after a thread goes away, > all of its copies of thread-local instances are subject to > garbage collection (unless other references to these copies exist). " > > As a developer you assume the thread will die after run is > complete. Or in the case of an RMI invocation, when the > invocation returns. The JDK developers were too shortsighted > to see that people might implement thread-pools. Otherwise > there would be a way to Clear the thread locals associated > with a thread. > > > > -----Original Message----- > > From: jbo...@li... > > [mailto:jbo...@li...]On Behalf Of > > Scott M Stark > > Sent: Thursday, January 16, 2003 2:03 PM > > To: jbo...@li... > > Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken > > > > > > I have no idea what you are talking about here. Thread > locals always > > work. The value of the variable is scoped by the thread. > What Bill is > > wanting is the ability to flush the variables associated > with a thread > > in the scope of a thread pool. This is a different semantic > that can > > be implemented as a map of thread locals accessed through > the thread > > pool. > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > ----- Original Message ----- > > From: "Jeff Haynie" <jh...@vo...> > > To: <jbo...@li...> > > Sent: Thursday, January 16, 2003 10:52 AM > > Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken > > > > > > > What happens in the case the executing thread doesn't know he's > > > executing on a thread pool thread - such as that another > caller is > > > calling a method on an object via a thread pool? In this > case, you > > > thread local variables wouldn't work -- in which case, > thread locals > > > are pointless, no? > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: Thawte.com > > Understand how to protect your customers personal information by > > implementing SSL on your Apache Web Server. Click here to > get our FREE > > Thawte Apache > > Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en > > _______________________________________________ > > Jboss-development mailing list > Jbo...@li... > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Thawte.com > Understand how to protect your customers personal information > by implementing SSL on your Apache Web Server. Click here to > get our FREE Thawte Apache > Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en > _______________________________________________ > Jboss-development mailing list Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-development > |