[Python-Dev] DTRACE support

[Nick Coghlan]

On 7 September 2013 19:06, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 7 Sep 2013 08:57:07 +0200
> Xavier Morel <python-dev at masklinn.net> wrote:
>>
>> On 2013-09-07, at 05:40 , Jesus Cea wrote:
>>
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 06/09/13 20:33, Antoine Pitrou wrote:
>> >> On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea <jcea at jcea.es> wrote:
>> >>>
>> >>> It is intrusive. Yes. I think it must be, by its own nature.
>> >>> Probably room for improvement and code transparency. But... are
>> >>> Python-DEVs interested in the project?. That is the point :)
>> >>
>> >> As a concrete data point: - here are Dave's modifications to
>> >> ceval.c for systemtap:
>> >> http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here
>> >> are your modifications to ceval.c for dtrace:
>> >> http://bugs.python.org/review/13405/diff/6151/Python/ceval.c
>> >
>> > Unfair, because that code is not doing the same thing.
>> >
>> > Most of the extra complexity is there to deal with DTRACE ability to
>> > provide meaningful stackframes, with Python code instead of CPython
>> > evaluation loop. This is kind of magical.
>>
>> Antoine will correct me if I'm wrong, but I believe his point is less
>> about the complexity of dtrace provision and more about how much of it
>> lives in ceval.c: the systemtap provision also takes quite a bit of
>> code, but almost all of that code is extracted into a separate file and
>> only a pair of calls live in ceval.c
>
> Yes, that's exactly my point. There can be an arbitrarily complex
> ceval-dtrace.h for all I care :-)
>
> Thanks for the examples, by the way.

Yep, complex stuff inline should be abstracted out so it doesn't
affect the code flow for those of us that don't care :)

Between Jesus, the Mac OS X using core devs and the Solaris and Mac OS
X buildbots it should be a maintainable addition.

However, it seems worthwhile to write up a short PEP (akin to the
tracemalloc PEP) to scope out the suggestion.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia