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
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.
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
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
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
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
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:
>>
>&g
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
> 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.
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
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
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
"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
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
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
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
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
"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
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
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
"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
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
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)
"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
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
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
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
> 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
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
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.
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
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_
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
"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
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
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
"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
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
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
48 matches
Mail list logo
