I think thread pools are different. SUN jdks do not have a thread pool. Supposedly thread creation is expensive on linux.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Thursday, January 16, 2003 3:22 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken > > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On > > Behalf Of Bill Burke > > Sent: Thursday, January 16, 2003 2:18 PM > > To: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > Scott M Stark > > > Sent: Thursday, January 16, 2003 2:03 PM > > > To: [EMAIL PROTECTED] > > > 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" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > 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 > > [EMAIL PROTECTED] > > > 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 [EMAIL PROTECTED] > > 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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
