Re: Thread implementations...

Albert D. Cahalan (acahalan@cs.uml.edu)
Thu, 25 Jun 1998 02:36:31 -0400 (EDT)


Dave Wragg writes:
> alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

>>> Both of these problem could be neatly solved if the kernel
>>> knew that thread-like processes live in teams. There are other
>>
>> Sort of a thread group like process group model. You need to do that
>> cleanly however to keep it fast and Linus happy.
>
> Last night I added a small amount of kernel support, so that I can
> modify LinuxThreads for direct thread creation and find out what the
> improvements to pthread_create might actually be.
>
> A CLONE_MINOR flag to clone creates a /minor process/. When a minor
> process clones/forks a new process, the parent of the new process is
> the parent of the minor process, rather than the minor process
> itself. So by using CLONE_MINOR, all the threads become child
> processes of the initial process.

You are doing two things with one flag:

1. Allow child to create siblings. (child is a minor process)
2. Actual sibling creation.

Perhaps it ought to be split into two flags, so that the parent can
itself be a minor process.

> should be easier than making CLONE_PID work properly, which would
> require the same sorts of changes plus adding thread IDs and some new
> syscalls).

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.

I think CLONE_PID doesn't look so impossible if you redefine the
contents of /proc as thread directories.

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