Date: Fri, 18 Apr 2003 17:12:31 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.org> Subject: RE: cvs commit: src/sys/sys proc.h Message-ID: <Pine.GSO.4.10.10304181702410.18230-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0304181336420.56212-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian, thanks for working on this. I am not so sure about the signal mask for the process though. I think the threads library (M:N) would always just keep everything unmasked. It's easier that way, and once the UTS is notified of a signal, then it can look for a thread to handle it or keep it pending (in the UTS). This way we don't have to keep a count of all the bits in all the threads masks and update them when a thread changes its mask. I am more concerned about the (kernel) thread masks being used instead of the mask in the mailboxes. Eventually, we need to address queued signals, so we might want to think about those requirements while we're messing with signaling. -- Dan Eischen On Fri, 18 Apr 2003, Julian Elischer wrote: > > On Fri, 18 Apr 2003, John Baldwin wrote: > > > > > On 18-Apr-2003 Julian Elischer wrote: > > > julian 2003/04/18 11:51:52 PDT > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/sys proc.h > > > Log: > > > Revert parts of 1.309 to allow processes to have a signal mask > > > independently from the threads again. > > > Will be adding code to use this soon.. > > > > *sigh* I guess I need to just throw away my 100k of diffs to cleanup > > proc locking. Can you and Jeff please sit down and develop a plan for > > what you both need for signals instead of just committing patches back > > and forth? Jeff at least has offered to rework signals if you will > > provide him with your interface requirements. I realize that may be a > > bit one-sided, so I don't really care who implements it, but I would > > like to see both of you sit down and come up with an interface w/o > > assuming a certain implementation first and once you have that in > > place then design an implementation that implements all the requirements. > > Please. People keep asking for proc locking but it can't be delivered > > if the code changes every week. > > Sorry, you have not made any indication that you didn't want anyone > touching this file.. but I won't put the code in without your ok. > > These fields are as they were before. > the code to use them has not been added yet. > > I am presuming that the locking for the td versions is the correct > locking for the proc versions. (they will be accessed at basically the > same times) but I'll send you the diffs first so you can check the > locking assumptions. At the moment M:N threads is working except that > there is a gross hack in it to gather all the signals in as they come in > at all the wrong places and redivert them to the right places. Also the > masking for M:N threads is all broken with synchronous signals. > > I'm trying to work out how to add code to the system that doesn't break > 1:1 threads but does what we need for M:N threads.. > > As I said.. this commit doesn't touch the fields yet. > I'm just 'reserving them'. > > > > > BTW, perhaps you and Jeff have already done all this in which case > > a 'Reviewed by' would have been _greatly_ appreciated. > > nope.. > the code when it happens will be reviewed by others, hopefully including > you. > This is just bringing back the presently unused fields. Nothing to > review yet. > > > > > > -- > > > > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304181702410.18230-100000>