Re: Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote:
> Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> writes:
> > On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> >> (In particular note that shutdown itself might be fired as an atexit
> >> callback, a move forced on us by exactly the sort of random user code
> >> that you want to add more of. It's not clear whether a Perl-added
> >> atexit would fire before or after that.)
>
> > man atexit says "Functions so registered are called in reverse order".
> > Since the plperl atexit is called only when a plperl SP or DO is
> > executed it would fire before any atexit() registered during startup.
>
> Right, which means that it would occur either before or after
> on_proc_exit processing, depending on whether we got there through
> an exit() call or via the normal proc_exit sequence. That's just
> the kind of instability I don't want to have to debug.

Okay. I could change the callback code to ignore calls if
proc_exit_inprogress is false. So an abnormal shutdown via exit()
wouldn't involve plperl at all. (Alternatively I could use use
on_proc_exit() instead of atexit() to register the callback.)

Would that address this call sequence instability issue?

> > The plperl subsystem is isolated from, and can't interact with, the
> > rest of the backend during shutdown.
>
> This is exactly the claim that I have zero confidence in. Quite
> frankly, the problem with Perl as an extension language is that Perl was
> never designed to be a subsystem: it feels free to mess around with the
> entire state of the process. We've been burnt multiple times by that
> even with the limited use we make of Perl now, and these proposed
> additions are going to make it a lot worse IMO.

On Wed, Jan 27, 2010 at 09:53:44AM -0800, David E. Wheeler wrote:
> Can you provide an example? Such concerns are impossible to address
> without concrete examples.

On Wed, Jan 27, 2010 at 01:08:56PM -0500, Tom Lane wrote:
> Two examples that I can find in a quick review of our CVS history: perl
> stomping on the process's setlocale state, and perl stomping on the
> stdio state (Windows only).

Neither of those relate to the actions of perl source code.
To address that, instead of calling perl_destruct() to perform a
complete destruction I could just execute END blocks and object
destructors. That would avoid executing any system-level actions.

Do you have any examples of how a user could write code in a plperl END
block that would interact with the rest of the backend?

Tim.