On 03-Jul-2002 Julian Elischer wrote: > > Expanding on my own mail: > > On Wed, 3 Jul 2002, Julian Elischer wrote: > >> On Wed, 3 Jul 2002, John Baldwin wrote: >> >> > >> > Well then it must be full of races then that were fixed since DP1. >> > *sigh* I wonder how many other things were lost and need to be >> > reimplemented. >> > > > Almost anything you checked into psignal will need looking at. > It may not be mising but since signals for threaded processes are > fundamentally different than signals for non threaded processes, some > things "just don't apply". > > for example if you checked in something to code that just doesn;t exist > any more in a KSE kernel, what is the correct integration? > > Each one has to be evaluated on it's own..
The one in question here was fairly simple, it just expanded the sched_lock locking some. The argument could be made that you shouldn't be checking in stuff until you know how it works, etc., or that you could commit in smaller pieces (say, get multiple threads per process for kernel processes working in the scheduler and just ignoring userland-only things like signals until you have the other working). -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
