#Yeah, I should have made that clearer. Do you get to choose whether #to use green or native threads on a per Java thread basis? Or you #have to commit to one model per Java app/JVM? #
You can actually switch between threading models.. There's an environment variable that you need to set (but it's implementation specific). For Linux, the Blackdown team already decided to dump green threads all together. Pero prior to 1.2, the JVM from Blackdown (which Sun uses) had a default threading model set to green threads. The Solaris version of Sun's JVM doesn't support green threads these days (?) too.. the Windows version never had green threads. #Hmmm you think so? That's the scenario I was mulling before... it #could be that Jython has to do something like the global interpreter #lock in CPython. # Let's step back a bit.. the glock interpreter lock is CPython's hack to support threading (much like green threads) where a thread needs to have ownership of the lock before it can *safely* access objects.. in so doing, in multi-threaded Python apps running on top of CPython, all method blocks are bound by critical sections. Again, this is solely because of how CPython was implemented and has nothing to do with Phython, the language. Now with jython, it's a totally different implementation. If you look at TheadState.java (org.python.core), it looks like a Python thread is mapped to a Java thread. Thus, it is limited only by the threading model of the underlying Java VM. For short, jython doesn't have the inherent limitations due to CPython's use to a global interpreter lock. stay cool. jeff -- -- Jeff Gutierrez Mapua Online! http://www.mapua.org http://www.mapua.com http://www.mapua.net Pinoy Ako! May reklamo? _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
