Date: Wed, 03 Jul 2002 05:47:52 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-current@freebsd.org Subject: Re: KSE signal problems still Message-ID: <XFMail.20020703054752.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0207030222010.1443-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020703054752.jhb>