From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paul_Woegerer@mentor.com (Woegerer, Paul)
Date: Fri, 27 Apr 2012 09:28:17 +0200
Subject: [lttng-dev] lttng enable-channel option for blocking
In-Reply-To: <20120426211627.GB1646@Krystal>
References: <4F992213.2090103@mentor.com> <20120426211627.GB1646@Krystal>
Message-ID: <4F9A4A91.7090102@mentor.com>

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.