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.
