lkml.org 
[lkml]   [1997]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: patch for CLONE_PID
Date
> I've been working on a better /bin/ps with johnsonm of Red Hat.
> Your system may be incompatible with other operating systems that
> have kernel thread support. It is easy to fix though: every tid
> must be unique. That means the tid can't be zero by default.

What I have done is make the tid zero by default, until something
tries to access it. There are only a couple of places that this can occur
right now:
1) gettid()
2) cat /proc/<pid>/status
3) ls /proc/<pid>/threads
4) do_fork (when CLONE_PID is used, a non-zero tid is allocated
for the clone, and if necessary for the parent.

If other places are needed, a call to set_thread_id() can be used to
create a non-zero tid for the task before any user space access of its tid
occurs.

Now that I think of it, one such place should be in sys_wait4. I have
added a new options flag __WRETURNTID, so that one can do:
wait4(pid, ..., __WRETURNTID | ...)
and wait for any thread of the process. With the patch as I posted it
the pid will be returned if that process's only task has no non-zero tid.

> If you must put threads right in /proc, please put a '.' in front
> of the number. There may be some tool that looks for a process by
> name and kills it. If such a tool finds a thread first, then only
> the thread gets killed.

I didn't know if anything did this right now, so I did a sort of hidden
tid directory in /proc. In one has process <pid>, with thread id <tid>, then
only pid will show up in an ls of /proc, but you can still change to the
/proc/<tid>. I admit this is sort of hack-ish, but it was easy (I have to
admit I thought it was kind of neat too:)

> The PID directory itself could be a link to the main thread,
> for now at least. Eventually it might be better to have the
> PID directory carry more complete information.

As above, there are probably much better ways to do it, but I was just
aiming for a short term solution. The proc interface wrt threads needs
to have some more thought put into it anyhow:

* What exactly goes in the /proc/pid directory?
* What should be thread specific?
* What needs to stay like it is for backwards compatibility?

I didn't really what to bother doing too much work on this until I knew
the answers for stuff like that.

Peeter
--
Peeter Joot
http://www.accessv.com/~peeter peeter@accessv.com

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