Re: why is imp_xxh stored in an SV?

On Fri, Feb 24, 2012 at 05:18:14PM +0000, Dave Mitchell wrote:
> (I confess I haven't looked closely at this yet, but...)

[And I confess I forgot about this message - sorry for the delay.]

> I seems that the imp_xxh_t structure is stored in the PVX of an SV
> pointed to by mg_obj.

The DBI is very old. I suspect it's was done that way because mg_obj had
to point to an SV in very old versions of perl. git blame says Larry
added MGf_REFCOUNTED to mg.h on 1994-05-04. The DBI in a very
rudamentary form back then. So it might have been that.

I also recall problems with global destruction order, in the early days,
that led to other oddities like the DBD::_mem::{dr,db,st} classes that
the imp_xxh_t struct gets blessed into:

    strcpy(imp_mem_name, imp_class);
    strcat(imp_mem_name, "_mem");
    imp_mem_stash = gv_stashpv(imp_mem_name, FALSE);
    ...
    dbih_imp_rv = newRV_inc(dbih_imp_sv);       /* just needed for sv_bless */
    sv_bless(dbih_imp_rv, imp_mem_stash);
    sv_free(dbih_imp_rv);

I hope that's ancient history now, but it might also be a dark corner
hiding a dragon.

> Is there any reason why it can't be just directly malloced and pointed
> to from mg_ptr instead?

Other than the issue above I can't think of any, except that it would
require drivers to be re-compiled.

Normally I'd say that requiring users to undergo the pain of a driver
recompile probably wouldn't be worth the (currently only presumed) gains.
But since we're already looking at a binary-incompatible change for the
DBIS macro, which I've also been trying to avoid, it looks more tempting.

If you can show a useful speed gain from the change (and no global
destruction issues on 5.8.3+) then I'll say we should require a
driver-compile and roll the new DBIS changes into that.

Sound good?

Tim.