On Sun, 07 Sep 2003 18:40:59 +0200, Tassilo von Parseval
<[EMAIL PROTECTED]> wrote:
>> 2) Calling call_xxx() without G_EVAL often doesn't work correctly when
>> your Perl sub can die(). Maybe it is just cargo cult, but I've been
>> bitten by this one too many times and now always specify G_EVAL and check
>> SvTRUE(ERRSV) myself to handle exceptions myself.
[...]
>I'll do a few tests and see whether not using G_EVAL can produce
>inconsistent results. I guess that
>
> if (SvTRUE(ERRSV)) croak(Nullch);
>
>would then fix them. Thanks for warning me!
The problem typically only manifests in a little more complicate
scenarios. That is, when the Perl code that calls your XS wraps the call
in an eval {} block and the Perl code called from your XS dies. Then Perl
(at least used to) get confused about stack frames.
You may want to take a look at this p5p thread:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=5b781e81ad8dd07&seekm=20020630130739.1394.2%40bactrian.elixent.com&frame=off
I have some code where even exiting the Perl interpreter must not
terminate the hosting process, so in addition to always passing G_EVAL I
also wrap the call in a JMPENV block (to catch exit() etc). And I put the
whole thing inside a try/catch block (in C++) to catch them if they call
another XS extension from their Perl code, and they have an access
violation in there. Still doesn't protect against user code calling
POSIX::_exit(), but then it is their own fault. :)
All that will be overkill for your situation, but I still think that not
using G_EVAL from XS is dangerous because you typically don't remember to
recheck your calls when you later change the called code.
Cheers,
-Jan
