On 04/26/2012 11:16 PM, Mathieu Desnoyers wrote:
I already thought about permitting this, but we currently don't. The
first thing I must say about this is that I prefer to wait a bit
before we add this feature, and think about its impact thoroughly,
because allowing the tracer to block applications gives a lot of power
to the tracer: e.g., if tracing is stopped due to error conditions, or
disk full, or network traffic slowdown, how do we handle the fact that
this might block progress in all traced applications ?
Good to know that this is on the agenda.
I agree, it gives a lot of power to the tracer. By messing with channel
configurations a user could make a tracing application unusable. But the
user already has ways to make applications unusable (by messing with
ulimit, for example). There is always enough rope to hang yourself.
The current modes (discard and overwrite) let the applications continue
even if there is too much data being recorded into the trace buffers --
this is a "safe" approach.
How would you recommend dealing with the possible pitfalls of blocking
traced applications ? We would need a mechanism in place to ensure
gathering a trace cannot make applications unresponsive.
I guess in case of "lttng enable-channel --block" a user would have to
expect that a call to tracepoint() might block. He has to deal with the
fact in his application domain (e.g. implement a watchdog mechanism).
Nonetheless it might be a good idea to also provide something like
tracepointnb() ( a non-blocking variant of tracepoint() ) in case the
user doesn't want to deal with (or simply cannot accept) potential blocking.
--
Thanks,
Paul
--
Paul Woegerer | SW Development Engineer
Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040 Austria
P 43.1.535991320
Nucleus® | Linux® | Android(tm) | Services | UI | Multi-OS
Android is a trademark of Google Inc. Use of this trademark is subject to
Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other
countries.
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
