Sacha Labourey wrote:
Sure it is. JRocket just has an abstraction that loosens the limit up considerable, but the limit is still there. JRocket is basically doing your pooling for you - yeah, it's a different mechanism than pooling but the effect is the same: you can program as if you can get a thread anytime you want, even though you might have to wait anyway.The Object pooling question was definately settled on the side of it's not worth it, but things like threads and sockets _are_ different in that the underlying OS has its own limits and imposes them on us.maybe for sockets, but not for threads: a JVM could have (andJRockit does)an abstraction layer between OS-threads and JVM-threads and do its own scheduling.Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive.Sure, but your e-mail did look like you were saying that it is a limit imposed by the OS on Java, while it is not.
To entirely get around the limit, the JVM has to completely take over the OS's scheduling role for the java application, which was what green threads did. I'd rather trust Linus, Ingo, and their hoard of contributors and testers to write a good general scheduling algorythm than anybody writing a proprietary VM.
-danch
-------------------------------------------------------
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
