Very good. Now we'll have FreeBSD starting up along the road Solaris (SVR4MP in some ways too) started on about 7 years ago. FreeBSD is an excellent system, and usually beats (performance-wise) any other Unix on a uniprocessor x86 in my experience. Scalability over more than 2 CPUs, however, is a question. Commercial Unixes have excellent scalability over dozens of CPUs; are we sure we really need this sort of performance for *BSD? Multithreading, however, is certainly becoming an important issue, and kernel scheduling of user thread groups (a la multiplexing over LWPs) is becoming something of a need. Are you sure that some sort of workaround cannot be done? Maybe add a signal to trigger rescheduling user threads, or enable the pthreads library to work over several rfork()ed processes? If it were possible to make rfork()ed processes multiplexed signal-wise over one PID, we could have something resembling LWP's.
Welcome to Solaris/SVR4. Necessary? I wonder. (Score:1)
FreeBSD is an excellent system, and usually beats (performance-wise) any other Unix on a uniprocessor x86 in my experience. Scalability over more than 2 CPUs, however, is a question. Commercial Unixes have excellent scalability over dozens of CPUs; are we sure we really need this sort of performance for *BSD?
Multithreading, however, is certainly becoming an important issue, and kernel scheduling of user thread groups (a la multiplexing over LWPs) is becoming something of a need. Are you sure that some sort of workaround cannot be done? Maybe add a signal to trigger rescheduling user threads, or enable the pthreads library to work over several rfork()ed processes? If it were possible to make rfork()ed processes multiplexed signal-wise over one PID, we could have something resembling LWP's.