Re: thread group comments

2000-09-04 Thread 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 th

Re: thread group comments

2000-09-03 Thread 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 fixe

Re: thread group comments

2000-09-03 Thread 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 en

Re: thread group comments

2000-09-03 Thread 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 d

Re: thread group comments

2000-09-02 Thread Mark Kettenis
DT) 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: >&

Re: thread group comments

2000-09-02 Thread 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 _

Re: thread group comments

2000-09-02 Thread Andi Kleen
On Fri, Sep 01, 2000 at 06:33:42PM -0700, Ulrich Drepper wrote: > "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

Re: thread group comments

2000-09-02 Thread 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

Re: thread group comments

2000-09-02 Thread 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. Yo

Re: thread group comments

2000-09-02 Thread Alan Cox
> I care. You only think you care... > 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-ba

Re: thread group comments

2000-09-01 Thread 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-

Re: thread group comments

2000-09-01 Thread 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. -- --

Re: thread group comments

2000-09-01 Thread 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 mo

Re: thread group comments

2000-09-01 Thread 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.0

Re: thread group comments

2000-09-01 Thread 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 cours

Re: thread group comments

2000-09-01 Thread 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 pthre

Re: thread group comments

2000-09-01 Thread 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,

Re: thread group comments

2000-09-01 Thread 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

Re: thread group comments

2000-09-01 Thread 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 imp

Re: thread group comments

2000-09-01 Thread 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 kern

Re: thread group comments

2000-09-01 Thread 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 nee

Re: thread group comments

2000-09-01 Thread 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 so

Re: thread group comments

2000-09-01 Thread 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 t

Re: thread group comments

2000-09-01 Thread 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 t

Re: thread group comments

2000-09-01 Thread 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) th

Re: thread group comments

2000-09-01 Thread 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 signa

Re: thread group comments

2000-09-01 Thread 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 han

Re: thread group comments

2000-09-01 Thread 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 _aft

Re: thread group comments

2000-09-01 Thread 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-wri

RE: thread group comments

2000-09-01 Thread 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

Re: thread group comments

2000-09-01 Thread 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.

Re: thread group comments

2000-09-01 Thread 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. > >

Re: thread group comments

2000-09-01 Thread 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 al

Re: thread group comments

2000-09-01 Thread 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

Re: thread group comments

2000-09-01 Thread 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. >

Re: thread group comments

2000-09-01 Thread 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 ther

thread group comments

2000-09-01 Thread 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