Re: thread group comments

[yodaiken]

On Sat, Sep 02, 2000 at 03:12:40AM +0200, Andi Kleen wrote:
> On Fri, Sep 01, 2000 at 06:11:05PM -0700, Ulrich Drepper wrote:
> > "Andi Kleen" <[EMAIL PROTECTED]> writes:
> > 
> > > Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 
> > 
> > I'm not sure whether it's worth the effort.  But I'm saying this now
> > looking at the code for another implementation following the 1:1 model.
> 
> So you have a different way to implement pthread_create without context
> switch to the thread manager in 2.4 ? 

What is the problem with the often proposed CLONE_PARENT solution?


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[yodaiken]

On Sat, Sep 02, 2000 at 03:12:40AM +0200, Andi Kleen wrote:
 On Fri, Sep 01, 2000 at 06:11:05PM -0700, Ulrich Drepper wrote:
  "Andi Kleen" [EMAIL PROTECTED] writes:
  
   Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 
  
  I'm not sure whether it's worth the effort.  But I'm saying this now
  looking at the code for another implementation following the 1:1 model.
 
 So you have a different way to implement pthread_create without context
 switch to the thread manager in 2.4 ? 

What is the problem with the often proposed CLONE_PARENT solution?


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Mark Kettenis]

   Date: Sat, 2 Sep 2000 11:56:05 -0700 (PDT)
   From: Linus Torvalds <[EMAIL PROTECTED]>

   > * SIGCONT isn't handled correctly:
   > 
   >   "[W]hen SIGCONT is generated for a process all pending stop signals
   >for that process shall be discarded."

   A lot of these issues should be fixed in test8-pre2. It does more of a
   true job of having shared signals instead of emulating them with a global
   "blocked" list and spreading them out to be local signals.

I looked at test8-pre2, and the basic strategy looks promising :-).

However folding CLONE_SIGHAND and CLONE_THREAD onto CLONE_SIGNAL
doesn't work.  The current LinuxThreads library uses CLONE_SIGHAND but
cannot deal with the thread group stuff (it relies on getpid()
returning the process ID of the thread and not the process ID of the
thread-group leader).  Basically locks up every existing
multi-threaded program.

Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alon Ziv]

I find I have to comment... although I haven't had access to my Linux box
for a while (Real Life is taking too much of my time ;-)

I, for one, am _not_ in favor of the tgid approach. I believe it is _far_
too complex a solution.
And, yes, I do have a better (IMNSHO) approach. I just didn't get enough
time to code it. It feels _really_ rude to counter code with words. Oh well.

What I believe should be done is just a few (simple) extensions to prctl.
Specifically, what we need is
* prctl(SEND_ME_PARENT_SIGNAL_x, s) --- tells kernel 'if my parent gets
signal x, send me signal s' (signals will be queued atomically). This way, a
thread can ask the kernel to be killed / stopped together with its parent.
* prctl(SIGNAL_ON_PARENT_EXEC, s) --- when parent _successfully_ exec's,
send me signal s.
And that is _all_. No tgid mess, no specific handling of specific signals in
the kernel, no 'all threads are blocking this signal' mess, no nada.

Now, userspace will be a different story. There, we'll need the following:
- When process does pthreads_init, it creates a new thread (N+1 model);
control returns via the _new_ thread (a la userspace thread-switch), and
original thread (which has the original pid) remains as master in a special
routine.
- Whenever a signal is handled _anywhere_ in the process, the master thread
sets a handler for it. It's the master thread's job to distribute signals;
also, when signal is blocked, it remains on master's queue. (If CLONE_SIGNAL
lets thread do the sigaction setup by itself--- even better, less ITC :-)
- New threads are created CLONE_PARENT. They ask to get SIGKILL on parent
SIGKILL, SIGSTOP on parent SIGSTOP, possibly also SIGSEGV on parent SIGSEGV
(and other 'terminating' signals). They also ask to get SIGKILL on parent
exec().
- Userspace exec() is rerouted (in _userspace_) to master thread. If it
succeeds, all other threads automagically disappear (they were SIGKILLed by
their own request); if it fails, return code gets back to originating thread
via same ITC mechanism.

Now, just when do I find the time to get a test8-pre1, rip out the silly
tgid stuff, and code my idea?!?

-az






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alon Ziv]

Title: 





I find I have to comment... although I haven't had access to my Linux box for a while (Real Life is taking too much of my time ;-)

I, for one, am _not_ in favor of the tgid approach. I believe it is _far_ too complex a solution.
And, yes, I do have a better (IMNSHO) approach. I just didn't get enough time to code it. It feels _really_ rude to counter code with words. Oh well.

What I believe should be done is just a few (simple) extensions to prctl.
Specifically, what we need is
* prctl(SEND_ME_PARENT_SIGNAL_x, s) --- tells kernel 'if my parent gets signal x, send me signal s' (signals will be queued atomically). This way, a thread can ask the kernel to be killed / stopped together with its parent.
* prctl(SIGNAL_ON_PARENT_EXEC, s) --- when parent _successfully_ exec's, send me signal s.


And that is _all_. No tgid mess, no specific handling of specific signals in the kernel, no 'all threads are blocking this signal' mess, no nada.

Now, userspace will be a different story. There, we'll need the following:
- When process does pthreads_init, it creates a new thread (N+1 model); control returns via the _new_ thread (a la userspace thread-switch), and original thread (which has the original pid) remains as master in a special routine.
- Whenever a signal is handled _anywhere_ in the process, the master thread sets a handler for it. It's the master thread's job to distribute signals; also, when signal is blocked, it remains on master's queue. (If CLONE_SIGNAL lets thread do the sigaction setup by itself--- even better, less ITC :-)
- New threads are created CLONE_PARENT. They ask to get SIGKILL on parent SIGKILL, SIGSTOP on parent SIGSTOP, possibly also SIGSEGV on parent SIGSEGV (and other 'terminating' signals). They also ask to get SIGKILL on parent exec().
- Userspace exec() is rerouted (in _userspace_) to master thread. If it succeeds, all other threads automagically disappear (they were SIGKILLed by their own request); if it fails, return code gets back to originating thread via same ITC mechanism.

Now, just when do I find the time to get a test8-pre1, rip out the silly tgid stuff, and code my idea?!?

-az


Alon Ziv 

System Architect (Client Team)

Zapper Technologies Inc. 

Tel +972-3-6949226

 




BEGIN:VCARD
VERSION:2.1
N:Ziv;Alon
FN:Alon Ziv
ORG:Zapper Technologies Inc.;Client
TITLE:System Architect
TEL;WORK;VOICE:+972 (3) 6949226
TEL;CELL;VOICE:+972 (54) 616935
TEL;WORK;FAX:+972 (3) 6965111
ADR;WORK:;;3 Azrieli Center;Tel-Aviv;;;Israel
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3 Azrieli Center=0D=0ATel-Aviv=0D=0AIsrael
KEY;X509;ENCODING=BASE64:
MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa
MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs
b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV
l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB
AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G
A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE
ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ
Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq
xqiELFqvBvDknKMGDfPJ


KEY;X509;ENCODING=BASE64:
MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa
MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs
b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV
l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB
AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G
A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE
ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ
Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq
xqiELFqvBvDknKMGDfPJ


KEY;X509;ENCODING=BASE64:
MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa
MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs
b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV

Re: thread group comments

[Alon Ziv]

Title: 





I find I have to comment... although I haven't had access to my Linux box for a while (Real Life is taking too much of my time ;-)

I, for one, am _not_ in favor of the tgid approach. I believe it is _far_ too complex a solution.
And, yes, I do have a better (IMNSHO) approach. I just didn't get enough time to code it. It feels _really_ rude to counter code with words. Oh well.

What I believe should be done is just a few (simple) extensions to prctl.
Specifically, what we need is
* prctl(SEND_ME_PARENT_SIGNAL_x, s) --- tells kernel 'if my parent gets signal x, send me signal s' (signals will be queued atomically). This way, a thread can ask the kernel to be killed / stopped together with its parent.
* prctl(SIGNAL_ON_PARENT_EXEC, s) --- when parent _successfully_ exec's, send me signal s.


And that is _all_. No tgid mess, no specific handling of specific signals in the kernel, no 'all threads are blocking this signal' mess, no nada.

Now, userspace will be a different story. There, we'll need the following:
- When process does pthreads_init, it creates a new thread (N+1 model); control returns via the _new_ thread (a la userspace thread-switch), and original thread (which has the original pid) remains as master in a special routine.
- Whenever a signal is handled _anywhere_ in the process, the master thread sets a handler for it. It's the master thread's job to distribute signals; also, when signal is blocked, it remains on master's queue. (If CLONE_SIGNAL lets thread do the sigaction setup by itself--- even better, less ITC :-)
- New threads are created CLONE_PARENT. They ask to get SIGKILL on parent SIGKILL, SIGSTOP on parent SIGSTOP, possibly also SIGSEGV on parent SIGSEGV (and other 'terminating' signals). They also ask to get SIGKILL on parent exec().
- Userspace exec() is rerouted (in _userspace_) to master thread. If it succeeds, all other threads automagically disappear (they were SIGKILLed by their own request); if it fails, return code gets back to originating thread via same ITC mechanism.

Now, just when do I find the time to get a test8-pre1, rip out the silly tgid stuff, and code my idea?!?

-az


Alon Ziv mailto:[EMAIL PROTECTED]

System Architect (Client Team)

Zapper Technologies Inc. http://www.zapper.com/

Tel +972-3-6949226

 




BEGIN:VCARD
VERSION:2.1
N:Ziv;Alon
FN:Alon Ziv
ORG:Zapper Technologies Inc.;Client
TITLE:System Architect
TEL;WORK;VOICE:+972 (3) 6949226
TEL;CELL;VOICE:+972 (54) 616935
TEL;WORK;FAX:+972 (3) 6965111
ADR;WORK:;;3 Azrieli Center;Tel-Aviv;;;Israel
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3 Azrieli Center=0D=0ATel-Aviv=0D=0AIsrael
KEY;X509;ENCODING=BASE64:
MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa
MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs
b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV
l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB
AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G
A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE
ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ
Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq
xqiELFqvBvDknKMGDfPJ


KEY;X509;ENCODING=BASE64:
MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa
MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs
b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV
l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB
AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G
A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE
ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ
Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq
xqiELFqvBvDknKMGDfPJ


KEY;X509;ENCODING=BASE64:
MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa
MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs
b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV
l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB
   

Re: thread group comments

[Mark Kettenis]

Because of my stupidity Linus' reply didn't make it to linux-kernel.
Here it is for those who're interested:

--- Start of forwarded message ---
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date: Sat, 2 Sep 2000 11:56:05 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
To: Mark Kettenis <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: thread group comments
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Sat, 2 Sep 2000, Mark Kettenis wrote:
>> 
>>  * Send a thread-group-wide signal.
>>  *
>>  * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.
>> 
>> That's OK.  Except that is a signal whose default action is to
>> terminate the process is not caught be the application, this signal is
>> also handled process-wide.  E.g., if there is no SIGSEGV handler the
>> whole process is terminated.
> 
>Fair enough.
> 
> Looking through the code in test8-pre1, I think there are more
> problems with (non-fatal) signals:
> 
> * sys_rt_sigqueueinfo() calls kill_proc_info() (to avoid the
>   "signal-to-pgid" semantics), but I think it should be calling
>   kill_tg_info().

Indeed. It makes sense to have rt_sigqueue() use the same logic as a
normal kill(). I just overlooked it entirely.

> * SIGCONT isn't handled correctly:
> 
>   "[W]hen SIGCONT is generated for a process all pending stop signals
>for that process shall be discarded."

A lot of these issues should be fixed in test8-pre2. It does more of a
true job of having shared signals instead of emulating them with a global
"blocked" list and spreading them out to be local signals.

(The "spread out the global signals" approach in test8-pre1 ends up being
fundamentally broken: it has various interesting problems with threads
dying or starting to block signals that they used to not block, and then
we should really give the signal we made local back to the global pool
etc. Nasty.).

> * The interaction between thread-groups and process-groups seems to be
>   wrong:
> 
>   Right now when a signal is sent to a process-group, it will be sent
>   to all tasks in the process-group.  I think however, that the signal
>   should be "sent" only to thread-group leaders in the process-group
>   and distributed to the threads according to the rules set by
>   kill_tg_info().

Possibly. The problem here is that it makes for very nasty locking.

Right now the thread groups are only known by synchronous threads: other
processes sending you a signal, or you yourself looking at your signals.
That means that they can use regular spinlocks to protect the shared
state.

In contrast, if you start doing the thread group semantics for
asynchronous things like ^C etc, we'd need to change that to
interrupt-safe spinlocks which are much more expensive and have other
nasty properties.

We'll see. I'd like to have people check out the shared semantics, and see
if it works reasonably well for pthreads, and we'll take care of remaining
details after the concept has been proven. 

The shared signals stuff actually ended up being fairly trivial: the most
work by far was the splitting up of functions to simplify the code and
allow re-use of the same stuff for the thread group logic and the single
thread logic. I think most of it is clearer now anyway, but there are some
locking issues still that need to be clarified.

Linus
--- End of forwarded message ---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Mark Kettenis]

   From: Linus Torvalds <[EMAIL PROTECTED]>
   Date: 2000-09-01 22:06:52

   On 1 Sep 2000, Ulrich Drepper wrote:
   > 2nd Problem: Fatal signal handling
   > 
   > kernel/signal.c contains:
   > 
   >  * Send a thread-group-wide signal.
   >  *
   >  * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.
   > 
   > That's OK.  Except that is a signal whose default action is to
   > terminate the process is not caught be the application, this signal is
   > also handled process-wide.  E.g., if there is no SIGSEGV handler the
   > whole process is terminated.

   Fair enough.

Looking through the code in test8-pre1, I think there are more
problems with (non-fatal) signals:

* sys_rt_sigqueueinfo() calls kill_proc_info() (to avoid the
  "signal-to-pgid" semantics), but I think it should be calling
  kill_tg_info().

* SIGCONT isn't handled correctly:

  "[W]hen SIGCONT is generated for a process all pending stop signals
   for that process shall be discarded."

  There is an ambiguity in the language here; should a SIGCONT
  generated for a thread-group discard a pending stop signal that was
  generated for a specific thread?  Probably yes.  Similar language is
  used for the stop signals (with respect to discarding SIGCONT), and
  in that case Linux discards a SIGCONT generated for a specific
  thread.

  In the current implementation all threads are continued until we
  encounter a thread that doesn't have SIGCONT blocked and doesn't
  ignore it.  This probably means that job-control is broken for
  thread groups.

* SIGTSTP, SIGTTIN, SIGTTOU seem to be mishandled too:

  "When a signal is delivered to a thread, if the action of that
   signal specifies termination, stop, or continue, the entire process
   shall be terminated, stopped or continued, respectively."

  Uli already addresses his concerns about termination by a fatal
  signal, but it looks as if similar problems exist for the signals
  that stop the process.  The default action for SIGTSTP, SIGTTIN or
  SIGTTOU should be to stop all threads in the process.

  This also seems to affect SIGCONT, i.e. what should be done for a
  SIGCONT sent to a specific thread?  The requirement that the entire
  process shall be continued seems to imply that it isn't possible to
  use SIGCONT to continue a specific thread.  In a POSIX world
  however, the only way such a signal could be generated by
  pthread_kill().  This means that the process wasn't stopped in the
  first place.

* The interaction between thread-groups and process-groups seems to be
  wrong:

  Right now when a signal is sent to a process-group, it will be sent
  to all tasks in the process-group.  I think however, that the signal
  should be "sent" only to thread-group leaders in the process-group
  and distributed to the threads according to the rules set by
  kill_tg_info().

   > 5th Problem: suspended starting
   > 
   > Related to the last problem a good old friend pops up.  Depending on
   > the solution of the last problem it might be necessary to add
   > suspended starting of threads.  The problem is that sometimes the
   > starter has to modify parameters (e.g., scheduler) of the newly
   > started thread before it can actually start working.  If this fails,
   > the new thread must be terminated immediately.  But who will get the
   > termination signal?  The data structures for the new thread must be
   > removed as well and this after the new thread is guaranteed to be
   > vanished.

   You can actually do this with CLONE_PTRACE right now.

How?  By letting the thread-group leader trace its cloned children,
and play tricks with PTRACE_SYSCALL?  Or are you going to change
things such that CLONE_PTRACE makes clone() send a SIGSTOP to the
newly created child (similar to a patch I sent you before?).

Doesn't this interfere with debugging?

Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alan Cox]

> The queued exit signal could carry which thread has died. The only tricky
> issue is what to do when the exit signal cannot be queued because there
> are too many threads in flight, in this case it makes sense to just make
> it pending without any data (the thread library can search some global
> data structure in this case)

And where it can and cannot be delivered priviledged. I think you need to
deliver SIGCLD to the real parent unless the proposed target pid is in the same
thread group, uid, gid.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alan Cox]

> I don't see how you can do this.  Also on user level you would have to
> do this atomically since otherwise communication between the threads
> isn't possible anymore.  We have a PR in the glibc bug data base about
> just that.  And I know that there are many other users with this
> problem.

You need to deliver a reserved signal to each thread then spin/sleep until
each one acks the request or dies. Its identical to a TLB shootdown in
the kernel. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alan Cox]

 I don't see how you can do this.  Also on user level you would have to
 do this atomically since otherwise communication between the threads
 isn't possible anymore.  We have a PR in the glibc bug data base about
 just that.  And I know that there are many other users with this
 problem.

You need to deliver a reserved signal to each thread then spin/sleep until
each one acks the request or dies. Its identical to a TLB shootdown in
the kernel. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alan Cox]

 The queued exit signal could carry which thread has died. The only tricky
 issue is what to do when the exit signal cannot be queued because there
 are too many threads in flight, in this case it makes sense to just make
 it pending without any data (the thread library can search some global
 data structure in this case)

And where it can and cannot be delivered priviledged. I think you need to
deliver SIGCLD to the real parent unless the proposed target pid is in the same
thread group, uid, gid.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

On Sat, 2 Sep 2000, Andi Kleen wrote:
> > tid = clone(CLONE_PID);
> 
> I'm not sure this will work very well (2.4.0test8-pre1):

Well, the above was written back when I hadn't done "CLONE_THREAD", so you
should really read CLONE_THREAD instead of CLONE_PID with the test8-pre1
semantics. 

Sorry for the confusion, I just cut-and-pasted from an older email

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> So you have a different way to implement pthread_create without context
> switch to the thread manager in 2.4 ? 

It should be possible to do these things with CLONE_PARENT.  It's a
long weekend coming up, let's see what I have next week.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> But I guess you don't want the context switch to a thread manager just to
> generate a thread ? (and which is one of the main causes of the bad thread 
> creation latency in Linux currently)

The thread manager, is I see it in the moment, will consist more or
less of this:

extern volatile int nthreads;
do
  waitpid (0, , __WCLONE)
while (nthreads > 0);
exit (WEXITSTATUS (res));

No signal handler, since it cannot receive signals.  Everything else
the threads will do themselves.

There is a problem though: the code we currently use for something
like restarting depends on the manager doing this.  This can be
implemented in two ways:

- send the manager a signal; this would require the threadkill() syscall
  already mentioned.  Note that we can assume RT signals and therefore
  can transport data.  But we get into problems if too many RT signals
  are queued.

- extend the loop above to something similar to what we have today:

do
  n = poll (..,..,.., timeout);
  check_for_dead_threads();  // use WNOHANG
  if (n > 0)
read request and process it
while (nthreads > 0)

  I really would like to avoid this.  It has the problems we are
  seeing today:

  * high latency of these requests
  * must adjust the priority of the manager (this now gets complicated
since it's not the manager which start the threads)
  * problems with changing UID/GID

It will require some investigation to see whether we can implement the
restart semantics correctly without a manager thread.  If yes, we
should be able to live with the simple loop.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 06:15:52PM -0700, Linus Torvalds wrote:
> 
> if (!has_done_this_before) {
> pid_t tid;
> has_done_this_before = 1;
> tid = clone(CLONE_PID);

I'm not sure this will work very well (2.4.0test8-pre1):

int do_fork(unsigned long clone_flags, unsigned long usp, struct pt_regs *regs)
{
int retval = -ENOMEM;
struct task_struct *p;
DECLARE_MUTEX_LOCKED(sem);

if (clone_flags & CLONE_PID) {
/* This is only allowed from the boot up thread */
if (current->pid)
return -EPERM;
}


So it would require fixing CLONE_PID first, which is probably nasty.

Without it it'll still require the context switches when you're calling
pthread_create from the "original" thread.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> Well, I would just swap it _before_ the clone() - basically in the
> original parent when you create the new stack, you call clone() with the
> new stack and with the old stack as the argument. No?

Yes.  I have it basically working.  You have of course to swap before
the clone since the new thread will use the stack.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

On Sat, 2 Sep 2000, Andi Kleen wrote:
> 
> But I guess you don't want the context switch to a thread manager just to
> generate a thread ? (and which is one of the main causes of the bad thread 
> creation latency in Linux currently)

No, you don't need that. Here it is again:

int pthread_create()
{
static int has_done_this_before = 0;
pid_t newtid;

if (!has_done_this_before) {
pid_t tid;
has_done_this_before = 1;
tid = clone(CLONE_PID);
if (tid > 0) {
/*
 *  original thread becomes hidden master
 * thread, and never returns
 */
i_am_the_master_thread();
exit(0);
}
/*
 * initial CLONE_PID thread comes here,
 * it is now one of the "regular children".
 */
}
newtid = clone(CLONE_PID | CLONE_PARENT);
.. now we have the two "pthread" threads here ..
}

and as Uli points out the only thing you need to do is to switch the
stacks around when you do the nasty "switch threads from under the users
feet" thing.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

On 1 Sep 2000, Ulrich Drepper wrote:
> 
> I see no big problems with this either.  The only tricky thing is to
> get the stack swapped after the first clone() but this is solvable.

Well, I would just swap it _before_ the clone() - basically in the
original parent when you create the new stack, you call clone() with the
new stack and with the old stack as the argument. No?

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

On Sat, 2 Sep 2000, Andi Kleen wrote:
> 
> The first goal would be to get it out of the critical path of pthread_create.

It should already be out of there. See the proposal I had earlier in this
thread, about the _first_ time only, when you have pthread_create(), you
do two clone() calls - and subsequently you just use CLONE_PARENT etc.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 06:11:05PM -0700, Ulrich Drepper wrote:
> "Andi Kleen" <[EMAIL PROTECTED]> writes:
> 
> > Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 
> 
> I'm not sure whether it's worth the effort.  But I'm saying this now
> looking at the code for another implementation following the 1:1 model.

So you have a different way to implement pthread_create without context
switch to the thread manager in 2.4 ? 



-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 

I'm not sure whether it's worth the effort.  But I'm saying this now
looking at the code for another implementation following the 1:1 model.

In a second stage where we have m kernel threads and n user-level
threads (the ultimate goal) things might be different.  But this is
beyond what is needed in the 2.4 kernel so lets just skip the
SA_NOCLDWAIT stuff for now.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 06:00:58PM -0700, Linus Torvalds wrote:
> 
> 
> On 1 Sep 2000, Ulrich Drepper wrote:
> 
> > "Andi Kleen" <[EMAIL PROTECTED]> writes:
> > 
> > > I've been thinking about how to best get rid of the thread manager for
> > > thread creation in LinuxThreads.  It is currently needed to do the wait.
> > 
> > If you get rid of the manager thread (the +1 thread) then you have
> > another problem: you cannot send a signal explicitly to this thread
> > (to implement pthread_kill).  The PID of this initial thread is now
> > used as the PID of the thread group.
> 
> Well, that can be solved by having a separate "threadkill()" system call. 
> 
> But I'd much rather just have the "n+1" thing. The overhead is basically
> nonexistent, and it simplifies so many things.

But I guess you don't want the context switch to a thread manager just to
generate a thread ? (and which is one of the main causes of the bad thread 
creation latency in Linux currently)

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> But I'd much rather just have the "n+1" thing. The overhead is basically
> nonexistent, and it simplifies so many things.

I see no big problems with this either.  The only tricky thing is to
get the stack swapped after the first clone() but this is solvable.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:

> True, but this can be handled by having the master thread process catch
> SIGSEGV and redistributing the signal to all of its child-threads.

No, it cannot.  We have to have a core dump with all threads.

> (The assumption I'm making here is that the master thread doesn't do
> anything except spawn all threads for the process and monitors its child
> processes for death.  This is the n+1 model.)

The master thread will not anymore spawn the threads.  That's the
whole purpose of this exercise.


-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 05:50:04PM -0700, Ulrich Drepper wrote:
> "Andi Kleen" <[EMAIL PROTECTED]> writes:
> 
> > I've been thinking about how to best get rid of the thread manager for
> > thread creation in LinuxThreads.  It is currently needed to do the wait.
> 
> If you get rid of the manager thread (the +1 thread) then you have
> another problem: you cannot send a signal explicitly to this thread
> (to implement pthread_kill).  The PID of this initial thread is now
> used as the PID of the thread group.

The first goal would be to get it out of the critical path of pthread_create.

I think Linus proposed to add a settid() system call later to generate 
a new thread id, when that one is there then you could use that tid and
remove it completely.

Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 



-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

On 1 Sep 2000, Ulrich Drepper wrote:

> "Andi Kleen" <[EMAIL PROTECTED]> writes:
> 
> > I've been thinking about how to best get rid of the thread manager for
> > thread creation in LinuxThreads.  It is currently needed to do the wait.
> 
> If you get rid of the manager thread (the +1 thread) then you have
> another problem: you cannot send a signal explicitly to this thread
> (to implement pthread_kill).  The PID of this initial thread is now
> used as the PID of the thread group.

Well, that can be solved by having a separate "threadkill()" system call. 

But I'd much rather just have the "n+1" thing. The overhead is basically
nonexistent, and it simplifies so many things.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

"Andi Kleen" <[EMAIL PROTECTED]> writes:

> I've been thinking about how to best get rid of the thread manager for
> thread creation in LinuxThreads.  It is currently needed to do the wait.

If you get rid of the manager thread (the +1 thread) then you have
another problem: you cannot send a signal explicitly to this thread
(to implement pthread_kill).  The PID of this initial thread is now
used as the PID of the thread group.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Theodore Y. Ts'o]

   From: Ulrich Drepper <[EMAIL PROTECTED]>
   Date:01 Sep 2000 14:52:28 -0700

   1st Problem:   One signal handler process process-wide

   What is handled correctly now is sending signals to the group.  Also
   that every thread has its mask.  But there must be exactly one signal
   handler installed.  I.e., a sigaction() call to set a new handler has
   consequences process-wide.  Since this muse be atomic I think the
   information should be kept in the thread group leader's data
   structures and the other threads should simply use this information
   all the time.  Yeah, I know, one more indirection.

Unfortunately, I think you're right.  This will mean an extra
indirection and locking, but signals aren't performance critical.

   2nd Problem: Fatal signal handling

   kernel/signal.c contains:

* Send a thread-group-wide signal.
*
* Rule: SIGSTOP and SIGKILL get delivered to _everybody_.

   That's OK.  Except that is a signal whose default action is to
   terminate the process is not caught be the application, this signal is
   also handled process-wide.  E.g., if there is no SIGSEGV handler the
   whole process is terminated.

True, but this can be handled by having the master thread process catch
SIGSEGV and redistributing the signal to all of its child-threads.

(The assumption I'm making here is that the master thread doesn't do
anything except spawn all threads for the process and monitors its child
processes for death.  This is the n+1 model.)

   This will have to go hand in hand with an extension of the core file
   format to include information about all threads but for the time being
   it's enough if only the offending thread is dumped and the rest simply
   killed.

True, although my bias has always been that if you wanted debuggable
programs, you wouldn't have been using threads in the first place.  :-)
(That was a joke, for the humor-impaired!)

   3rd Problem: one uid/gid process-wide

   All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
   is similar to the signal handler.  I think one should again keep the
   information exclusively in the master thread and have all others refer
   to this information.

This will probably have to be emulated in user-mode via IPC's.  UID
changes don't happen often, and they're **NOT** performance critical.
The aternative is to put locking around all of the uid/gid checks in the
mainline kernel code, and that's been considered unreasonable.

   4th Problem: thread termination

   In general, thread termination is not of much interest for the rest of
   the system.  It is in the moment but if the fatal signal handling is
   done this will change.

   If a thread gets a fatal signal, the whole process is killed.  No
   cleanup necessary.  Signal handlers can be installed if necessary.

   If a thread terminates naturally and can perform the cleanup itself.

   In any case, the death signal should be ignored.  Except for the last
   thread, of course, which has to notify the process starting the MT
   application.

I assume here that when you say "death signal" you mean SIGCHLD?  If so,
if all threads are children of the master thread, then the master thread
will get all of the SIGCHLD's, and it can deal with them appropriately.
(In fact, the master thread can get the notification that one of the
threads died due to an unhandled SEGV, and it can use that information
to kill off all over the other threads.)

   5th Problem: suspended starting

   Related to the last problem a good old friend pops up.  Depending on
   the solution of the last problem it might be necessary to add
   suspended starting of threads.  The problem is that sometimes the
   starter has to modify parameters (e.g., scheduler) of the newly
   started thread before it can actually start working.  If this fails,
   the new thread must be terminated immediately.  But who will get the
   termination signal?  The data structures for the new thread must be
   removed as well and this after the new thread is guaranteed to be
   vanished.

Umm why can't this be done in user space?  We can do it in kernel
space, but it means adding a new flag to clone() which tells it to
suspend the child immediately and let the parent return.  Why can't it
be done in userpsace by having the library which calls clone() as part
of starting a new thread suspend itself if it's the child?  I must be
missing something.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 03:06:52PM -0700, Linus Torvalds wrote:
> 
> Good that _somebody_ actually looked at the code. I'll make some more
> modifications to handle blocked signals correctly (ie handling the case
> where the signal is blocked in all threads and then unblocked in one of
> them _after_ it was delivered), but I've been disappointed by how much hot
> air there's been on the list, and how little comments on how the actual
> code works.

I've been looking at the code and I think it could be extended a bit:

I've been thinking about how to best get rid of the thread manager for
thread creation in LinuxThreads.  It is currently needed to do the wait.

I think the easiest way is to just implement the Single Unix SA_NOCLDWAIT 
and add a prctl to set a queued exit signal to some arbitary pid. That pid 
could be the thread group so some thread would just handle it and do the 
necessary LinuxThreads bookkeeping.
The queued exit signal could carry which thread has died. The only tricky
issue is what to do when the exit signal cannot be queued because there
are too many threads in flight, in this case it makes sense to just make
it pending without any data (the thread library can search some global
data structure in this case)

All these changes are very easy.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alexander Viro]

On Fri, 1 Sep 2000, Linus Torvalds wrote:

> Oh, I basically agree, _except_ that Al Viro has these ideas pending for
> 2.5.x that basically create a "process capability cache" that is a cache
> of all the process ID's and capabilities (ie uid, gid, groups etc). Which
> would be this copy-on-write thing.
> 
> And that may end up mixing well with a "CLONE_CAPABILITIES" flag.

I don't think so. Look: suppose we've got two processes sharing the
credentials pointer. Fine. We also have something else (e.g. opened file
or pending NFS request, etc.) sharing these creds. Now we do the setgid().
How would it know that we want to have creds of the second process
changed, but creds of everything else left unchanged? "Partial copy-on-write"
is an odd thing...

BTW, idea is hardly mine - it goes back at least to early 90s (as
do the problems that make it useful).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: thread group comments

[David Schwartz]

> 3rd Problem: one uid/gid process-wide
>
> All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> is similar to the signal handler.  I think one should again keep the
> information exclusively in the master thread and have all others refer
> to this information.

Other than that it's required by the POSIX standard, can you see any real
use for this? It's generally an obstacle you have to code around.

What I would suggest is that the Linux kernel continue the way it is. The
race conditions in this are unavoidable, so let's just acknowledge them and
live with them.

The pthreads library can do the horrible deed of getting each thread to
change it's *id. At the very worst, add a kernel facility to change all the
*ids in a group and let the pthreads library code use it.

But to hack the kernel to have one set of *ids for all the threads is
illogical. It would make it unduly hard to have different threads serving
requests on behalf of different clients with different security contexts.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

Alan Cox <[EMAIL PROTECTED]> writes:

> You dont want it in kernel space.

I don't see how you can do this.  Also on user level you would have to
do this atomically since otherwise communication between the threads
isn't possible anymore.  We have a PR in the glibc bug data base about
just that.  And I know that there are many other users with this
problem.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Jeff V. Merkey]

Linus Torvalds wrote:
> 
> 
> Yes. For 2.4.x, I'd love to fix anything that can be used to show real
> performance bugs. Something like "setuid() is slow when I run it threaded
> is not a real issue". Something like "pthreads is faster under NT than
> under Linux" _would_ be a real issue.
> 
> Linus
> 

pthreads is faster on NT than Linux.  It has to do with how they create
shared segments for local data to apps.  It's about twice as fast as
what's in Linux.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Brian Wellington]

On Fri, 1 Sep 2000, Linus Torvalds wrote:

> > 3rd Problem: one uid/gid process-wide
> > 
> > All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> > is similar to the signal handler.  I think one should again keep the
> > information exclusively in the master thread and have all others refer
> > to this information.
> 
> No, it would be another "clone" option. 
> 
> But I don't think this is performance-critical, and I don't think it is
> something people really care about. So I'd be unlikely to handle this for
> 2.4.x.

I care.

Having written lots of Linux-specific code in BIND 9 to work around this
problem in LinuxThreads, I'd really like to see it work correctly
(correctly meaning according to posix, in this case).

Basically, on every non-Linux platform, we can start threads, parse the
config file in a thread, create new privileged sockets to listen on, and
then call setuid().  On Linux, that doesn't work, because the call to
setuid() only affects the running thread, which means we need to rework
the above logic into a capability-based mess.

This is not a performnace critical operation, but not implementing in the
kernel makes user space jump through some pretty large hoops.  The
solution would probably involve lots of inter-thread messages, which if I
remember correctly, these changes were supposed to remove.

I'd imagine other people have similar concerns...

Brian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

On Fri, 1 Sep 2000, Alan Cox wrote:
> > 
> > No, it would be another "clone" option. 
> 
> You dont want it in kernel space.

Oh, I basically agree, _except_ that Al Viro has these ideas pending for
2.5.x that basically create a "process capability cache" that is a cache
of all the process ID's and capabilities (ie uid, gid, groups etc). Which
would be this copy-on-write thing.

And that may end up mixing well with a "CLONE_CAPABILITIES" flag.

Which is not to say that this will necessarily get done. But other changes
may make it an option. I was just saying that if done that way, it would
be a CLONE_ flag instead of "we will use the thread leaders ID" thing.

> Its also very rare and not a performance case to push into glibc

Yes. For 2.4.x, I'd love to fix anything that can be used to show real
performance bugs. Something like "setuid() is slow when I run it threaded
is not a real issue". Something like "pthreads is faster under NT than
under Linux" _would_ be a real issue.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Alan Cox]

> > 3rd Problem: one uid/gid process-wide
> > 
> > All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> > is similar to the signal handler.  I think one should again keep the
> > information exclusively in the master thread and have all others refer
> > to this information.
> 
> No, it would be another "clone" option. 

You dont want it in kernel space. Not unless you plan to lock uid/gid access
and make them atomic. Think about things like file operations where the uid
changes under you on another CPU as you walk a directory tree checking
permissions.. 

Quota looks even more horrible.

Its also very rare and not a performance case to push into glibc

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

Good that _somebody_ actually looked at the code. I'll make some more
modifications to handle blocked signals correctly (ie handling the case
where the signal is blocked in all threads and then unblocked in one of
them _after_ it was delivered), but I've been disappointed by how much hot
air there's been on the list, and how little comments on how the actual
code works.

Thanks, Uli/.

On 1 Sep 2000, Ulrich Drepper wrote:
> 
> 1st Problem:   One signal handler process process-wide
> 
> What is handled correctly now is sending signals to the group.  Also
> that every thread has its mask.  But there must be exactly one signal
> handler installed.  I.e., a sigaction() call to set a new handler has
> consequences process-wide.  Since this muse be atomic I think the
> information should be kept in the thread group leader's data
> structures and the other threads should simply use this information
> all the time.  Yeah, I know, one more indirection.

We already do this. This is exactly what CLONE_SIGHAND does.

Having looked at the problem some more, it appears to never really make
sense to have CLONE_THREAD and CLONE_SIGHAND be separate. Basically,
either you share signals or you don't. Pthreads shares them. I'll make it
a single flag, and we'll have CLONE_SIGNAL (same as old CLONE_SIGHAND),
and that will be a "signal group" aka "thread group".

> 2nd Problem: Fatal signal handling
> 
> kernel/signal.c contains:
> 
>  * Send a thread-group-wide signal.
>  *
>  * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.
> 
> That's OK.  Except that is a signal whose default action is to
> terminate the process is not caught be the application, this signal is
> also handled process-wide.  E.g., if there is no SIGSEGV handler the
> whole process is terminated.

Fair enough. 

> 3rd Problem: one uid/gid process-wide
> 
> All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
> is similar to the signal handler.  I think one should again keep the
> information exclusively in the master thread and have all others refer
> to this information.

No, it would be another "clone" option. 

But I don't think this is performance-critical, and I don't think it is
something people really care about. So I'd be unlikely to handle this for
2.4.x.

> 4th Problem: thread termination
> 
> In general, thread termination is not of much interest for the rest of
> the system.  It is in the moment but if the fatal signal handling is
> done this will change.
> 
> If a thread gets a fatal signal, the whole process is killed.  No
> cleanup necessary.  Signal handlers can be installed if necessary.
> 
> If a thread terminates naturally and can perform the cleanup itself.
> 
> In any case, the death signal should be ignored.  Except for the last
> thread, of course, which has to notify the process starting the MT
> application.

This is why you should have the "n+1" approach. The "+1" thing is the one
that sees the "n" threads die. The parent of the threaded process is the
one that sees the "+1" die.

> I can see two possible solutions, neither of which I've tried:
> 
> - the termination signal given to clone calls is 0 (zero).  So no
>   notification is sent out.  Question is: does the kernel allow this?

Yes, as far as I can tell. I still don't think you should do it directly
like this.

> 5th Problem: suspended starting
> 
> Related to the last problem a good old friend pops up.  Depending on
> the solution of the last problem it might be necessary to add
> suspended starting of threads.  The problem is that sometimes the
> starter has to modify parameters (e.g., scheduler) of the newly
> started thread before it can actually start working.  If this fails,
> the new thread must be terminated immediately.  But who will get the
> termination signal?  The data structures for the new thread must be
> removed as well and this after the new thread is guaranteed to be
> vanished.

You can actually do this with CLONE_PTRACE right now.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

thread group comments

[Ulrich Drepper]

I hoped somebody else would write something about Linus' test8-pre1
thread group changes but I haven't seen anything.  Now you have to
bear with me even though I'm incompetent[1].

I took a look at the code and thought about the changes
necessary/possible in the thread library.  Here's what I came up with
so far:


1st Problem:   One signal handler process process-wide

What is handled correctly now is sending signals to the group.  Also
that every thread has its mask.  But there must be exactly one signal
handler installed.  I.e., a sigaction() call to set a new handler has
consequences process-wide.  Since this muse be atomic I think the
information should be kept in the thread group leader's data
structures and the other threads should simply use this information
all the time.  Yeah, I know, one more indirection.



2nd Problem: Fatal signal handling

kernel/signal.c contains:

 * Send a thread-group-wide signal.
 *
 * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.

That's OK.  Except that is a signal whose default action is to
terminate the process is not caught be the application, this signal is
also handled process-wide.  E.g., if there is no SIGSEGV handler the
whole process is terminated.

This will have to go hand in hand with an extension of the core file
format to include information about all threads but for the time being
it's enough if only the offending thread is dumped and the rest simply
killed.


3rd Problem: one uid/gid process-wide

All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
is similar to the signal handler.  I think one should again keep the
information exclusively in the master thread and have all others refer
to this information.



4th Problem: thread termination

In general, thread termination is not of much interest for the rest of
the system.  It is in the moment but if the fatal signal handling is
done this will change.

If a thread gets a fatal signal, the whole process is killed.  No
cleanup necessary.  Signal handlers can be installed if necessary.

If a thread terminates naturally and can perform the cleanup itself.

In any case, the death signal should be ignored.  Except for the last
thread, of course, which has to notify the process starting the MT
application.

I can see two possible solutions, neither of which I've tried:

- the termination signal given to clone calls is 0 (zero).  So no
  notification is sent out.  Question is: does the kernel allow this?

- the kernel ignores the SIGCHLD signal for all threads except the last
  one

In any case is there the problem how to handle the termination of the
master thread.  If it is not aware of starting and terminating threads
I could imagine some user-level mechanisms to make this work but they
are not very clean (it involves changing the death signal in the
thread depending on the situation).  If there is something people
think the kernel could do this would be probably better.


5th Problem: suspended starting

Related to the last problem a good old friend pops up.  Depending on
the solution of the last problem it might be necessary to add
suspended starting of threads.  The problem is that sometimes the
starter has to modify parameters (e.g., scheduler) of the newly
started thread before it can actually start working.  If this fails,
the new thread must be terminated immediately.  But who will get the
termination signal?  The data structures for the new thread must be
removed as well and this after the new thread is guaranteed to be
vanished.

Anyway, I still think it's not even worth discussing this much since
the whole change to implement this is only a few lines.  And it's in
no fastpath.



I might have more if I get deeper into implementation details.  But if
the above problems could be fixed we'd be a long way down the read to
a good implementation.


[1] Since Linus says so it must be true.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Jeff V. Merkey]

Linus Torvalds wrote:
 
 
 Yes. For 2.4.x, I'd love to fix anything that can be used to show real
 performance bugs. Something like "setuid() is slow when I run it threaded
 is not a real issue". Something like "pthreads is faster under NT than
 under Linux" _would_ be a real issue.
 
 Linus
 

pthreads is faster on NT than Linux.  It has to do with how they create
shared segments for local data to apps.  It's about twice as fast as
what's in Linux.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: thread group comments

[David Schwartz]

 3rd Problem: one uid/gid process-wide

 All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
 is similar to the signal handler.  I think one should again keep the
 information exclusively in the master thread and have all others refer
 to this information.

Other than that it's required by the POSIX standard, can you see any real
use for this? It's generally an obstacle you have to code around.

What I would suggest is that the Linux kernel continue the way it is. The
race conditions in this are unavoidable, so let's just acknowledge them and
live with them.

The pthreads library can do the horrible deed of getting each thread to
change it's *id. At the very worst, add a kernel facility to change all the
*ids in a group and let the pthreads library code use it.

But to hack the kernel to have one set of *ids for all the threads is
illogical. It would make it unduly hard to have different threads serving
requests on behalf of different clients with different security contexts.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 03:06:52PM -0700, Linus Torvalds wrote:
 
 Good that _somebody_ actually looked at the code. I'll make some more
 modifications to handle blocked signals correctly (ie handling the case
 where the signal is blocked in all threads and then unblocked in one of
 them _after_ it was delivered), but I've been disappointed by how much hot
 air there's been on the list, and how little comments on how the actual
 code works.

I've been looking at the code and I think it could be extended a bit:

I've been thinking about how to best get rid of the thread manager for
thread creation in LinuxThreads.  It is currently needed to do the wait.

I think the easiest way is to just implement the Single Unix SA_NOCLDWAIT 
and add a prctl to set a queued exit signal to some arbitary pid. That pid 
could be the thread group so some thread would just handle it and do the 
necessary LinuxThreads bookkeeping.
The queued exit signal could carry which thread has died. The only tricky
issue is what to do when the exit signal cannot be queued because there
are too many threads in flight, in this case it makes sense to just make
it pending without any data (the thread library can search some global
data structure in this case)

All these changes are very easy.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Theodore Y. Ts'o]

   From: Ulrich Drepper [EMAIL PROTECTED]
   Date:01 Sep 2000 14:52:28 -0700

   1st Problem:   One signal handler process process-wide

   What is handled correctly now is sending signals to the group.  Also
   that every thread has its mask.  But there must be exactly one signal
   handler installed.  I.e., a sigaction() call to set a new handler has
   consequences process-wide.  Since this muse be atomic I think the
   information should be kept in the thread group leader's data
   structures and the other threads should simply use this information
   all the time.  Yeah, I know, one more indirection.

Unfortunately, I think you're right.  This will mean an extra
indirection and locking, but signals aren't performance critical.

   2nd Problem: Fatal signal handling

   kernel/signal.c contains:

* Send a thread-group-wide signal.
*
* Rule: SIGSTOP and SIGKILL get delivered to _everybody_.

   That's OK.  Except that is a signal whose default action is to
   terminate the process is not caught be the application, this signal is
   also handled process-wide.  E.g., if there is no SIGSEGV handler the
   whole process is terminated.

True, but this can be handled by having the master thread process catch
SIGSEGV and redistributing the signal to all of its child-threads.

(The assumption I'm making here is that the master thread doesn't do
anything except spawn all threads for the process and monitors its child
processes for death.  This is the n+1 model.)

   This will have to go hand in hand with an extension of the core file
   format to include information about all threads but for the time being
   it's enough if only the offending thread is dumped and the rest simply
   killed.

True, although my bias has always been that if you wanted debuggable
programs, you wouldn't have been using threads in the first place.  :-)
(That was a joke, for the humor-impaired!)

   3rd Problem: one uid/gid process-wide

   All the ID (uid/guid/euid/egid/...) must be process wide.  The problem
   is similar to the signal handler.  I think one should again keep the
   information exclusively in the master thread and have all others refer
   to this information.

This will probably have to be emulated in user-mode via IPC's.  UID
changes don't happen often, and they're **NOT** performance critical.
The aternative is to put locking around all of the uid/gid checks in the
mainline kernel code, and that's been considered unreasonable.

   4th Problem: thread termination

   In general, thread termination is not of much interest for the rest of
   the system.  It is in the moment but if the fatal signal handling is
   done this will change.

   If a thread gets a fatal signal, the whole process is killed.  No
   cleanup necessary.  Signal handlers can be installed if necessary.

   If a thread terminates naturally and can perform the cleanup itself.

   In any case, the death signal should be ignored.  Except for the last
   thread, of course, which has to notify the process starting the MT
   application.

I assume here that when you say "death signal" you mean SIGCHLD?  If so,
if all threads are children of the master thread, then the master thread
will get all of the SIGCHLD's, and it can deal with them appropriately.
(In fact, the master thread can get the notification that one of the
threads died due to an unhandled SEGV, and it can use that information
to kill off all over the other threads.)

   5th Problem: suspended starting

   Related to the last problem a good old friend pops up.  Depending on
   the solution of the last problem it might be necessary to add
   suspended starting of threads.  The problem is that sometimes the
   starter has to modify parameters (e.g., scheduler) of the newly
   started thread before it can actually start working.  If this fails,
   the new thread must be terminated immediately.  But who will get the
   termination signal?  The data structures for the new thread must be
   removed as well and this after the new thread is guaranteed to be
   vanished.

Umm why can't this be done in user space?  We can do it in kernel
space, but it means adding a new flag to clone() which tells it to
suspend the child immediately and let the parent return.  Why can't it
be done in userpsace by having the library which calls clone() as part
of starting a new thread suspend itself if it's the child?  I must be
missing something.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

"Andi Kleen" [EMAIL PROTECTED] writes:

 I've been thinking about how to best get rid of the thread manager for
 thread creation in LinuxThreads.  It is currently needed to do the wait.

If you get rid of the manager thread (the +1 thread) then you have
another problem: you cannot send a signal explicitly to this thread
(to implement pthread_kill).  The PID of this initial thread is now
used as the PID of the thread group.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Linus Torvalds]

On 1 Sep 2000, Ulrich Drepper wrote:

 "Andi Kleen" [EMAIL PROTECTED] writes:
 
  I've been thinking about how to best get rid of the thread manager for
  thread creation in LinuxThreads.  It is currently needed to do the wait.
 
 If you get rid of the manager thread (the +1 thread) then you have
 another problem: you cannot send a signal explicitly to this thread
 (to implement pthread_kill).  The PID of this initial thread is now
 used as the PID of the thread group.

Well, that can be solved by having a separate "threadkill()" system call. 

But I'd much rather just have the "n+1" thing. The overhead is basically
nonexistent, and it simplifies so many things.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 05:50:04PM -0700, Ulrich Drepper wrote:
 "Andi Kleen" [EMAIL PROTECTED] writes:
 
  I've been thinking about how to best get rid of the thread manager for
  thread creation in LinuxThreads.  It is currently needed to do the wait.
 
 If you get rid of the manager thread (the +1 thread) then you have
 another problem: you cannot send a signal explicitly to this thread
 (to implement pthread_kill).  The PID of this initial thread is now
 used as the PID of the thread group.

The first goal would be to get it out of the critical path of pthread_create.

I think Linus proposed to add a settid() system call later to generate 
a new thread id, when that one is there then you could use that tid and
remove it completely.

Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ? 



-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

"Theodore Y. Ts'o" [EMAIL PROTECTED] writes:

 True, but this can be handled by having the master thread process catch
 SIGSEGV and redistributing the signal to all of its child-threads.

No, it cannot.  We have to have a core dump with all threads.

 (The assumption I'm making here is that the master thread doesn't do
 anything except spawn all threads for the process and monitors its child
 processes for death.  This is the n+1 model.)

The master thread will not anymore spawn the threads.  That's the
whole purpose of this exercise.


-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Ulrich Drepper]

Linus Torvalds [EMAIL PROTECTED] writes:

 But I'd much rather just have the "n+1" thing. The overhead is basically
 nonexistent, and it simplifies so many things.

I see no big problems with this either.  The only tricky thing is to
get the stack swapped after the first clone() but this is solvable.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: thread group comments

[Andi Kleen]

On Fri, Sep 01, 2000 at 06:15:52PM -0700, Linus Torvalds wrote:
 
 if (!has_done_this_before) {
 pid_t tid;
 has_done_this_before = 1;
 tid = clone(CLONE_PID);

I'm not sure this will work very well (2.4.0test8-pre1):

int do_fork(unsigned long clone_flags, unsigned long usp, struct pt_regs *regs)
{
int retval = -ENOMEM;
struct task_struct *p;
DECLARE_MUTEX_LOCKED(sem);

if (clone_flags  CLONE_PID) {
/* This is only allowed from the boot up thread */
if (current-pid)
return -EPERM;
}


So it would require fixing CLONE_PID first, which is probably nasty.

Without it it'll still require the context switches when you're calling
pthread_create from the "original" thread.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/