Roland,
On Tue, Nov 13, 2007 at 06:04:02PM -0800, Roland McGrath wrote:
> Inside the kernel, you can use utrace for this. At the moment, there is no
> new canonical user-level interface that hooks into the utrace facilities.
Yes, I would need this at the user level for monitoring tools to detect
termination of monitored threads.
> So if you are looking for a replacement for ptrace in that sense, the
> utrace layer per se does not fulfill that role by itself.
>
I think monitoring tools would need only a subset of what ptrace does:
1/ ability to stop another thread and have the guarantee that upon
return from the syscall, the thread is actually off the CPU.
2/ ability to detach and resume execution
3/ ability to get notifications on:
- fork, vfork
- exec
- exit
- pthread_create
- termination (different from exit: guarantee thread is off CPU)
I know that ptrace already provides 1/, 2/, 3/ and in fact I am using this today
in pfmon. But I don't like the ther side effects such as signal forwarding.
Another property of ptrace() that we leverage is the fact that there can only be
one ptracing parent. When operating on a monitored thread's PMU state, we need
that thread stopped, thus ptrace_check_attach(). But we also need to guarantee
that nobody can wakeup the thread (kill -CONT for instance) while we operate on
it.
> If you already have your own kernel code and a sufficient way for it to
> communicate with user-level (e.g. whatever you use for monitor events),
> then it is simple to use utrace in that kernel code to give a callback when
> the thread is dying. Since I imagine you already have your own per-thread
> context in the kernel for perfmon and some hook by which to clean it up,
> this may not be buying you anything at all.
>
> Depending what you need, utrace too might be overkill. It avoids many
> important drawbacks of ptrace, but it does entail more complexity than
> might be warranted for something really basic. What utrace gives you is
> synchronous notification, i.e. instant and with some possibility to
> interlock with other bookkeeping before the process could be reaped (and
> its PID reused if you don't have other get_task_struct refs on it). If you
> don't need that, there may be other options already in the upstream kernel.
> For example, there is "connector", though AFAICT that only lets you ask for
> all thread deaths across the whole system. There might be some sort of
> /proc polling or inotify or something that works (I haven't looked into that).
>
Somebody suggested inotify. I tired that yesterday and it does not work on
/proc files because they are generated on demand, too bad. Maybe this is
something that could be extended. I'll ask robert love (author of inotify).
Thanks for your detailed answer.
--
-Stephane
