Thread implementations (CLONE_PID, ...)

Peeter Joot (peeter@joot.com)
Fri, 26 Jun 1998 01:43:35 -0400 (EDT)


Hi David,

A while back I had started some work on some stuff that is similar to
to what it sounds like you are doing. I have some patches with
different stages of the work I was doing at http://www.accessv.com/~peeter

Among the kinds of things I was doing was:

* changing the parent child relationships (I think similar to what you are
doing).
* sharing more of the struct task_struct stuff (groups, uid, ...) between
threads
* some small changes to exec for threads
* handling signal stuff so that process group/thread stuff is not all
messed up
* changes to proc so that threads info could be gotten (grouped by pid).
* fixing getppid
* a few other things

I think that the best feature of all my changes was simply changing a few
find_task_by_pid() calls to find_task_by_id(). The latter first did the
lookup of the pid and then a lookup of the tid if that didn't turn up
a task_struct entry. In this way any most system calls that were
pid centric could be modified to work uniformly with thread ids with
a one character change. Thread ids were added to task_struct and there
is no messy complicated stuff like using the upper bits of the pid.

All of the wait/kill and parent child task hierarchy stuff I implemented
should probably be scrapped because I didn't think it through quite enough
and it's rather complicated code. I think I got a bit confused when
trying to figure out exactly what wait4 should do wrt threads, processes,
and ptrace after my changes were made (I think that I still don't entirely
understand the semantics of wait4/ptrace).

I haven't been working on this for a long time, but if you are working
on similar stuff you may want to incorporate parts of this in your
changes, or at least some of the ideas.

The basic problem that with my approach was that I was trying to change
too many things at one time. I should have taken one part at a time, and
gotten it working well enough to get integrated into the kernel at that
point once all the issues were resolved.

Peeter

--
Peeter Joot
http://www.accessv.com/~peeter  peeter@accessv.com, Peeter_Joot@ca.ibm.com

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