On Wed, Jul 27, 2005 at 01:06:32PM -0700, Dean Arnold wrote:
> >
> > DBI->connect(..., { dbi_imp_data => $imp_data })
>
> Already read that, which is what kinda got me concerned
> in the 1st place. In TQD terms, you're "curse()"ing the underlying
> connection object into a frozen scalar, then
> thawing and "redeem()"ing the scalar back to the underlying
> connection object in the borrowing thread.
> But there could be a *lot* of context stuff, and the
> take_imp_data() comments from DBI.xs don't give me a warm
> fuzzy feeling either.
>
> I spose for XS-based DBD's, assuming they've been carefully
> crafted to not stray from those rules, its not a big deal (few or no
> SV/AV/etc's to manage to recover context).
>
> I think Stas mentioned he'd only tested with DBD::mysql; have
> any other DBD's been tested with this ?
> >Pure perl drivers are free to return any chunk of data, as a string, so
> >long as it can be used to recover the connection information. So for a
> >pure perl driver using a socket, $imp_data could be the integer file
> >descriptor of the socket. Note that it can't (shouldn't) be a reference
> >to a filehandle object since references can't easily be passed between
> >threads.
>
> That definitely bothers me (having written a number of PP drivers).
> Not impossible, but certainly an added burden for DBD authors, and
> certainly an opportunity for things to go awry in very strange ways.
> And statement handles could be even worse...
>
> And only serves to convince me that apt. threading, tho a bit on the beefy
> side, is a better solution for my needs.
You've not offered any concrete example of any problems.
Tim.
