* [Bug translator/13187] New: Reconsider the semantics of process(number).thread.begin/end
@ 2011-09-13 21:11 brolley at redhat dot com
2011-09-14 14:31 ` [Bug translator/13187] " dsmith at redhat dot com
2016-05-26 17:57 ` fche at redhat dot com
0 siblings, 2 replies; 3+ messages in thread
From: brolley at redhat dot com @ 2011-09-13 21:11 UTC (permalink / raw)
To: systemtap
http://sourceware.org/bugzilla/show_bug.cgi?id=13187
Bug #: 13187
Summary: Reconsider the semantics of
process(number).thread.begin/end
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
AssignedTo: systemtap@sourceware.org
ReportedBy: brolley@redhat.com
CC: dsmith@redhat.com, fche@redhat.com
Classification: Unclassified
The current semantics of process(number).thread.begin and
process(number).thread.end are to select threads with the given task id and to
fire probes as these threads begin and end respectively.
While this is logical, given the internal semantics of process(number).begin
and process(number).end, which fire probes at the corresponding beginning and
end of the main threads of a process, it is not very useful. This is because
the task ids of individual threads within a process are difficult, if not
impossible, to predict in advance. The result is that these probes serve no
reasonably useful purpose.
The difference, which makes process(number).begin and process(number).end
useful is that, for these probes, the task id matches the process id, which is
easily obtained by the user.
Other variants of thread.begin and thread.end are useful because of additional
semantics:
- process("PATH").thread.begin and process("path").thread.end fire at the
beginning and end of each child thread of processes corresponding to the given
path. From a user's point of view this represents all child threads beginning
and ending within the processes associated with that path.
- the commands
stap -e 'process.thread.begin {}' -c PATH
and
stap -e 'process.thread.end {} -c PATH
have a similar effect with the firing of the probes at the beginning and end of
each child thread within the process started by running the executable at PATH.
Once again, from the user's point of view, this represents all child threads
beginning and ending within that process.
So, when a user wants to probe the same thing against an already-running
process, it would seem reasonable that process(PID).thread.begin and
process(PID).thread.end might do the same thing. That is, fire at the beginning
and end of each child thread within the process PID. After all, she has simply
substituted the process ID for the path used in the previous examples. In other
words, she has attempted to identify the target process(es) in a different
manner.
However, for a running process, these probes will currently never fire, because
the task ids of the child threads do not match the given process id.
I propose that the process(PID).thread.begin and process(PID).thread.end probes
assume the same semantics as the other thread.begin and thread.end variants by
firing at the beginning and end of the child threads of the given process as
the other variants do. That is these probes should adopt the same "follow all
children" semantics as the other variants.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug translator/13187] Reconsider the semantics of process(number).thread.begin/end
2011-09-13 21:11 [Bug translator/13187] New: Reconsider the semantics of process(number).thread.begin/end brolley at redhat dot com
@ 2011-09-14 14:31 ` dsmith at redhat dot com
2016-05-26 17:57 ` fche at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: dsmith at redhat dot com @ 2011-09-14 14:31 UTC (permalink / raw)
To: systemtap
http://sourceware.org/bugzilla/show_bug.cgi?id=13187
--- Comment #1 from David Smith <dsmith at redhat dot com> 2011-09-14 14:28:23 UTC ---
(In reply to comment #0)
> However, for a running process, these probes will currently never fire, because
> the task ids of the child threads do not match the given process id.
There is a situation where process(PID).thread.begin probes will fire.
- Start a process that creates several threads that will run for an extended
period of time. Determine the pids of those threads.
- RUn systemtap with a script that probes those pids.
- As systemtap attaches to those threads, the process(PID).thread.begin probe
will fire.
In my opinion, changing the semantics here is too big/messy of a change.
Instead, a new probe type, something like 'process(PATH/PID).thread.create',
could be created.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug translator/13187] Reconsider the semantics of process(number).thread.begin/end
2011-09-13 21:11 [Bug translator/13187] New: Reconsider the semantics of process(number).thread.begin/end brolley at redhat dot com
2011-09-14 14:31 ` [Bug translator/13187] " dsmith at redhat dot com
@ 2016-05-26 17:57 ` fche at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: fche at redhat dot com @ 2016-05-26 17:57 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=13187
Frank Ch. Eigler <fche at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
neat idea, but no recent need
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-05-26 17:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-13 21:11 [Bug translator/13187] New: Reconsider the semantics of process(number).thread.begin/end brolley at redhat dot com
2011-09-14 14:31 ` [Bug translator/13187] " dsmith at redhat dot com
2016-05-26 17:57 ` fche at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).