lkml.org 
[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Thread implementations...
From
Date
"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
> Dave Wragg writes:
> > "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
> >> Maybe CLONE_PID ought to be your CLONE_MINOR. It would be very good
> >> to kill the current CLONE_PID, since /proc can not handle it.
> >> Let's think of /proc as having thread ID directories, not process ID
> >> directories. The process ID is equal to the thread ID of the manager
> >> thread. We just need a way to tell procps that not all threads in /proc
> >> are manager threads, perhaps with /proc/$TID/threads files.
> >
> > This appears easy enough to do. The procfs code just has to omit minor
> > threads from the normal process listing, and put them in the directory
> > of the leader thread instead.
>
> It is better to avoid that, because it is unnecessarily complicated.
> The existing CLONE_PID is simply bad. The concept isn't bad.
> Solution: /proc has numeric directories, named by _thread_ ID.
>
> Example: We have process 10, which is a normal process. Like all
> processes, it has a manager thread with a TID equal to the PID.
> This process becomes multithreaded. We get something like this:
>
> /proc/10 original thread, now the manager. PID==TID
> /proc/13 thread 13 (system-wide numer) has PID 10 also
> /proc/42 another thread with PID 10
> /proc/78 another thread with PID 10
>

Well, this is what we have already. With my minor processes stuff, the
"virtual pid" can be found by checking if the process has PF_MINOR
set, if so its virtual pid is its ppid, otherwise its virtual pid is
its real pid.

The only issue with this is that if, for instance, you have fifty
normal processes, and one thread group with 500 threads, ps has a lot
of work to do in order to hide the threads. Having procfs hide the
threads is complicated, but might be a saving.

> >> I think CLONE_PID doesn't look so impossible if you redefine the
> >> contents of /proc as thread directories.
> >
> > In principle completing CLONE_PID is not much more work than what I'm
> > doing. However, for every place where the kernel exposes a pid to
> > userspace, somene will need to consider whether a thread equivalent is
> > needed and if so write the code. Which sounds like a lot of trouble
> > for something we can do perfectly well without.
>
> You planned to fix signal handling, right?

Well, at the moment I'm just trying to get the cost of a
pthread_create closer to the cost of a clone. Once that is done,
fixing signal handling (having minor process handle signals for the
manager) will be straightforward. But first I have to get hold of the
POSIX 1b spec so I can make sure I do it right.

> With that and the stuff
> you already wrote, I'd say you have a working CLONE_PID.

I should have a working CLONE_PID equivalent. It isn't CLONE_PID
because it doesn't.

> The current
> CLONE_PID looks like bad news for security and hasn't been useful.
> I would suggest that you just recycle the CLONE_PID name and bit.

We're not running short of clone flag bits just yet, and reusing the
name will only confuse people. When there's a fast complete pthreads
implementation for Linux with the kernel parts accepted by Linus, then
I'll be happy to give CLONE_PID the chop.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.045 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site