cvs commit: src/sys/sys proc.h

[John Baldwin]

On 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.

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 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..

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.

> 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.

>> 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. :)

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/