This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: what does 'probe process(PID_OR_NAME).clone' mean?


> Does this make sense as the script-level view?

I think what you've described maps well to the formulation I presented.
The one area where it's hazy to me what precisely you intend is what in
debugging parlance is the run vs attach issue.  Here I mean start-up of a
process/thread observed by systemtap (run) vs starting a systemtap session
meant to apply to existing processes/threads.

The existing sense of plain begin/end probes in systemtap is the start and
finish of the systemtap session.  So one can construe a process(...).begin
or .thread.begin probe to mean "the process/thread joined the session",
i.e. either creation during the session or the start of the session when
the applicable process/thread already existed.  (And likewise, .end being
both death and session-end.)

It sounded a little more like you meant .begin just to be newborn-child and
.end just to be death, but as I said it's hazy to me.  

The latter sense doesn't really make sense for a process(PID).begin probe,
since by definition the PID process already exists before the session
starts.  Also, I think any sense that excludes session start/end, for a
thread that is live throughout, is sufficiently disparate from the meaning
of the gloal begin/end probe in a subtle way that it is very dubious to use
the same names.  However, I am also hazy on the desireability of always
conflating the thread lifetime with the session lifetime.

Can you elaborate more precisely on your ideas for the by-PID cases?
What do you think about the whole thread lifetime vs session lifetime issue?


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]