Date: Fri, 18 Apr 2003 14:30:33 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/sys proc.h Message-ID: <Pine.BSF.4.21.0304181421260.56212-100000@InterJet.elischer.org> In-Reply-To: <XFMail.20030418170836.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 18 Apr 2003, John Baldwin wrote: > > On 18-Apr-2003 Julian Elischer wrote: > > > > I don't want others to not touch this file, I just don't want to see a > commit war unfold in the future is all. > > > These fields are as they were before. > > the code to use them has not been added yet. > > > > > > 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.. > > I think here there is room for more input at the design stage. Perhaps > that is happening on threads@ (which I'm not reading ATM, E2MUCHEMAIL)? > I just would like to the see the design hammered out before a lot of > code gets written as it is easier to change the design when you don't > have a pile of code already depending on it. All the design was done aboth 6 months ago on the KSE mailing list. unfortunatly all that went straight out the window when the signal masks were moved from the process to the thread. The current attempt is to see if we can make the code "modal" so that it acts as it did before when in M:N mode and as it does now otherwise. It's not a perfect solution however as it adds a lot of complexity to the signal code. One posibility I'm looking at is having our own signal code in the M:N files and using that instead when a process goes to M:N mode. The downside of that is duplicated code. it may be that I end up doing a hybrid, where signal handling code initially calls into some entrypoints in the appripriate threading module, (via some pointers in the proc structure) which, after figuring out what to do according to M:N rules, calls standard worker functions to do the work.. (e.g. deliver a signal to a thread or whatever). > > > As I said.. this commit doesn't touch the fields yet. > > I'm just 'reserving them'. > > Ok, I had assumed that since you brought back the fields you had code > ready to commit as well. One thing that might help simplify this a good > bit is if I can get the compat.patch patch I just posted to current > committed first as that will remove several direct references to the > signal masks and might help to minimize the number of places that might > be changed, hopefully making everyone's life easier. I won't be ready to commit for a few days so if yuo get that committed, I'll use that as a base to work from. > > >> 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. > > Designs can be reviewed too, not just code. :) I'll run the design past you offline..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0304181421260.56212-100000>