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.