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
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
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
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
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:
>&
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 _
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
> 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
> 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
> 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
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-
"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.
--
--
"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
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
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
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
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,
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
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
"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
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
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
"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
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
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
"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
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
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
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
> 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
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.
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.
>
>
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
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
> > 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.
>
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
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
37 matches
Mail list logo
