Re: Initial refactoring of plperl.c [PATCH]

On Sat, Nov 28, 2009 at 09:35:10AM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
>> - Changed MULTIPLICITY check from runtime to compiletime.
>> No loads the large Config module.
>
> ISTM the trouble with this is that it assumes that the library that we
> compile with is the same as the library loaded at runtime. But there
> is no guarantee of that at all.

It only assumes that the library that we compile with has the same
'architecture' (archname) the library loaded at runtime--and that's a
fundamental assumption of the libperl binary API.

There is no guarantee of binary compatibility in the perl API between
multiplicity and non-multiplicity builds. That's clearly indicated by
'multi' being included in the archname.

It happens to work at the moment only because certain parts of the API
haven't been used yet. For example, the patch I'm working on at the
moment adds:

PL_exit_flags |= PERL_EXIT_DESTRUCT_END;

as part of a fix for bug #5066. PL_exit_flags expands to very different
(and binary incompatible) code for a perl built with multiplicity
compared to without.

(Similarly, another change I'd like to make, given the time, is to
enable use of PERL_NO_GET_CONTEXT. That would reduce the juggling of
global interpreter variables and eliminate the need for functions like
restore_context(). In return it'll eliminate almost all the hidden calls
to pthread_getspecific() for perls built with threads enabled.)

In summary, changing between multiplicity and non-multiplicity libperls
after building postgresql isn't safe or supported.

Tim.