Sorry for this flurry of half-researched questions... :-( I'll probably be able to submit another patch to DBI::DBD.pm out of this.
On Wed, 15 Dec 2004 10:11:57 +0000, Tim Bunce <[EMAIL PROTECTED]> wrote: > On Tue, Dec 14, 2004 at 06:24:40PM -0800, Jonathan Leffler wrote: > > On Tue, 14 Dec 2004 16:47:39 +0000, Tim Bunce <[EMAIL PROTECTED]> wrote: > > > [...] > > > > OK - well, I've removed the Err, Errstr, State parameters from the > > calls to _new_drh and _new_dbh and things seem to be working better > > for me in DBD::Informix.. > > > > I'm now trying to work out how the DBIh_SET_ERR_SV() and - more > > particularly - DBIh_SET_ERR_CHAR() functions can be used. I've > > spotted the section of DBI::DBD that discusses these - and I note that > > it deprecates the use 'dbis' and 'DBIS' shortly afterwards. > > DBIS is slow for threaded perl and probably broken for multiplicity > perls (perl configured with -DMULTPLICITY). > > Any code that has a handle can change > DBIS->foo > to > DBIc_DBISTATE(imp_xxh)->foo > > and will run faster in threaded perl. That assumes you have an imp_xxh around to work with. In some of the contexts, I don't, which is why the code is still messing with DBIS. I faintly remember trying to do something about it back in (early) 2003 -- unless it was 2001 -- and not coming to any useful conclusion. I'll end up doing somewhat more major surgery than I originally expected. It's what happens when you neglect software for 4 years. > > I have a pair of central error reporting functions - for $drh and $dbh > > as it happens - but they get passed only the imp_drh_t or imp_dbh_t > > pointers and not an associated SV. Is there a way to get back to the > > SV from the imp_d?h_t pointer? > > You can use h = newRV((SV*)DBIc_MY_H(imp_xxh)); > or h = sv_2mortal(newRV((SV*)DBIc_MY_H(imp_xxh))); > > The newRV is needed because DBIc_MY_H returns a pointer to an HV > struct, not an RV reference to an HV. You'd probably need the > sv_2mortal to free the reference returned by newRV else you'd leak. > > > There are two problems I'm having. One: what is the significance of > > the SV *h and the imp_xxh_t * arguments? > > The SV *h is the handle (the same as $h in the perl code, only > typically it's the "inner" handle) - it's an RV to a HV. > > The imp_xxh_t *imp_xxh is the "implementors data structure". > Direct fast access to your own data structure. > > > Why are both needed; > > The SV handle is what perl gives you when it calls your function, > but the implementors data structure is typically what you want. > Getting from the SV to the imp_xxh_t is relatively expensive so > best to do it as little as possible. > > But to do some things you need the SV, so that's why both get passed > around a lot. > > The DBIc_MY_H() way to get back the handle from the imp_xxh_t is > relatively new. There may be some potential issues with it though > I think you can use it here. But note that the sv_2mortal(newRV(...)) > means it's more expensive. > > I'd recommend just passing both values around. Thanks; that's helpful. > > what should those values be. > > I'm not sure what you're asking there. Nor me - sorry. > > The other problem may be indirectly related. DBD::Informix has some > > (debugging) functions which I want to invoke from code that is > > unrelated to Perl - and therefore should not be contaminated with Perl > > nasties like SV pointers. At the moment, that code is using DBIS to > > find the debug level. The code does not have 'h' or 'imp_xxh' values > > available to it -- so it uses the DBIS to obtain the information it > > needs. > > If you don't want code "contaminated" then I'd recommend passing > in the debug level as a parameter. > > DBIS will work, but it's slow for threaded perls and broken for > multiplicity perls. OK - I'll do something about it. -- Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h> Guardian of DBD::Informix - v2003.04 - http://dbi.perl.org "I don't suffer from insanity - I enjoy every minute of it."
