At any rate, thread pooling should actually be pretty easy to wire in; the instantiation of a native thread was one of the first things I abstracted out when originally reworking the threading stuff. I wouldn't expect you'd have to rip out a lot of stuff.
On 6/14/06, Ola Bini <[EMAIL PROTECTED]> wrote:
Hi,
Probably later today, I'll do some experimenting with making JRuby threads
into a ThreadPool instead. This would _probably_ make performance MUCH
better in cases such as the ruby gems download.
I plan to use doug lea's concurrency library and a standard PooledExecutor
for this. I will probably have to implement a subclass of Thread and a
ThreadFactory that enables me to get hold of the current Runnable, but this
is a small task. My first plan was to try to change as few things as
possible, but I think it will work better if I rip out what isn't right and
just try to get it working with pooling instead, so we can see what
benefits this strategy gives us.
It shouldn't really impair functionality, since if we use an unbounded
Pool, there will always be enough threads to use.
Any thoughts?
Regards
Ola Bini
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
_______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
