Hi, Just to clarify a few things. There is very little difference in performance between a user based green_threads implementation and a kernel threads (native) implementation (except for scheduling rules) on single processor systems. If done well, user based threads can even be faster than kernel based (native) threads on single processor systems due to the need to set and restore a smaller context (less overhead during switching). The v3 version of jdk116 uses non-blocking io for all io system calls including stdin (that was one of the fixes for v3). So user threads do not (should not!) block on io and the entire user based thread package does not stop. This works as follows: A call is made to an read from an fd (which has already been set to be non-blocking). It will return errno equal to EAGAIN immediately if no data is ready to be read. That user thread will then enter a waiting list and yield to the next thread. It will stay that way until a sigio comes in. The signal handler does a select() to determine which of the waiting threads are ready to run (i.e. their file descriptor is ready for io) and that thread is awakened. I hope this description helps. Although the green threads model catches alot of flack, it it not that much different from a user-based pthreads implementation. Sun just needs to fine tune it abit more "some might say a lot!". Hopefully a native threads version will come soon (a few people are working on it), but don't expect a big performance boost on uni-processor machines. Please let me know if I haven't explained this well. I hope this helps. Kevin Linux PPC JDK porting team [EMAIL PROTECTED] ---------------------------------------------------------- Kevin B. Hendricks Associate Professor, Operations & Information Technology School of Business, College of William & Mary Williamsburg, VA 23187, [EMAIL PROTECTED] http://business.tyler.wm.edu
