Front page | perl.perl5.porters |
Postings from September 2023
Re: Native stack traces?
Thread Previous
|
Thread Next
From:
Ovid
Date:
September 8, 2023 15:42
Subject:
Re: Native stack traces?
Message ID:
CA+M4CHux4kfB3iNBsyUo1rJYjidiNE=NC5KP=2yfy6iEBLUuYw@mail.gmail.com
On Fri, Sep 8, 2023 at 3:01 PM demerphq <demerphq@gmail.com> wrote:
>
>> > i think what ovid is getting at that there could be value in moderately
>> configurable stacktrace generators implemented in the perl c core, with the
>> hope that those could be considerably faster than the only current way of
>> getting the data out of the internals, then munging it at the perl level
>>
>
Yes, that's what I was hoping.
> Yeah, this could be implemented as an XS module.
>
> I think the problem with this kind of request is that there are an awful
> lot of possible options that could be applied. Do you show arguments or
> not? If you do, do you show the raw value or do you filter them, or do you
> transform them to show type only, etc. Do you show hints flags? Do you show
> the file and line? Do you munge the filename? Do you show the full stack?
> Do you not? How do you interoperate with eval, etc. It turns out that
> there are lot of options there...
>
What I'm hoping was that some of this could be native to a C implementation
with "default" behavior, with a possibility to override some bits in Perl,
but still have the ability to have the rest done in C. Of course, if you
override too much, you'll not get much benefit over just having a pure Perl
version. That means a core version might be fast, with minor customization
available, but if you need to upgrade, there are still CPAN modules
available.
*Most* of the time, I just want a quick stack trace with the ability to
hide scalar values so that PII doesn't leak. Thus, I can generate a stack
trace and write it to the logs with less concern about exposing secrets,
and with less concern that it's a performance or memory hit if I do it a
lot (which happens in the nightmare case of a bug that can't be reproduced
outside of production, for example).
But whether or not that is realistic, I can't say. For a few exception
objects I've found, a common anti-pattern is to use exceptions for flow
control (throw, catch it up the stack, and ignore the error). Those
exceptions often have a stack trace, so a faster, reliable solution would
be nice for them (though they should stop generating those damned traces in
that case).
That being said, I fully acknowledge that this might be too little benefit
for the reward.
Best,
Ovid
--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/
Thread Previous
|
Thread Next