On Thu, Sep 20, 2001 at 11:55:55AM -0700, Jonathan Leffler wrote:
> Moved to dbi-dev as this is getting much more like a dev issue than
> a general dbi-users issue.
>
> On Thu, 20 Sep 2001, Tim Bunce wrote:
> >On Wed, Sep 19, 2001 at 05:49:26PM -0700, Jonathan Leffler wrote:
> >> On Wed, 19 Sep 2001, Tim Bunce wrote:
> >> >On Wed, Sep 19, 2001 at 11:24:39AM -0500, James Maes wrote:
> >> >> On Wednesday 19 September 2001 11:16 am, James Maes wrote:
> >> >> > On Wednesday 19 September 2001 10:51 am, Tim Bunce wrote:
> >> >> > > Actually the DBI uses a mutex *per driver* thus ensuring that
> >> >> > > only a single thread can enter each driver. But different
> >> >> > > threads could go through the DBI into different drivers at the
> >> >> > > same time.
> >> >> > >
> >> >> > > One subtle point to note: if multiple interpreters are being used
> >> >> > > (such as mod_perl 2, or ActiveState's IIS thingy) then you can
> >> >> > > have multiple DBI's and DBD::Foo's loaded. One per perl
> >> >> > > interpreter. As the mutexes are per interpreter there's nothing
> >> >> > > to stop two threads getting into the same underlying database
> >> >> > > libraries via two separate perl+DBI+DBD::Foo's.
> >> >> >
> >> >> > Would it be possible for an application with multiple threads all
> >> >> > working from the same driver be able to init N-threads, each thread
> >> >> > with a separate connection to the database. From what I see, that
> >> >> > would be okay, but o two threads would be able to use their connect
> >> >> > at the same time. The driver forces everything to be
> >> >> > synchronized...
> >> >>
> >> >> type-O ("but NO two threads....");
> >> >
> >> >Probably :)
> >> >
> >> >Trace level [mumble] adds thread mutex info to the trace output. Test it out.
> >>
> >> OK. DBD::Informix currently does not expect to play threads. It
> >> handles multiple connections OK, and stores all the data for each
> >> statement associated with the connection in the statement handle, so all
> >> that should be fine. You'd have to experiment to ensure that
> >> DBD::Informix can be compiled in a threaded environment (basically,
> >> making sure that there are enough "dThr;" declarations at the top of
> >> functions to be safe.
> >
> >Actually it was dTHR I think. But I _think_ that kind of threading
> >is deprecated in more recent versions of Perl which now use something
> >called EXPLICIT_CONTEXT (from memory).
>
> Oh? How on earth (or any other appropriate venue - hell figured
> in the first version of this sentence) are we, the poor dumb DBD
> writers, to keep in touch which such things? How are we even
> supposed to know which bits of the Perl kernel we have to worry
> about? And, more particularly, what does 'more recent versions
> of Perl' mean in this context.
>
> Multi-threading is always tough. If there is stuff that has to
> be done to keep multi-threaded stuff safe, then we need to know
> how to do that. And it has to be simple - we are not all
> multi-threading experts.
I agree entirely. Which is why the DBI just does enough to keep
the driver authors from having to worry about such things (as
far as is possible).
> Also, I need to go back to Tim's comment:
>
> One subtle point to note: if multiple interpreters are being
> used (such as mod_perl 2, or ActiveState's IIS thingy) then
> you can have multiple DBI's and DBD::Foo's loaded.
>
> So, each interpreter would have its own $drh for DBB::Foo.
Yes.
> With
> such a scheme, DBD::Informix would not know that it needed to
> generate distinct connection names between the interpreters, so
> the different Perl interpreters would inevitably share connection
> names, leading to confusion to all and sundry! Is there a
> recommended mechanism for this? At the moment, there's a
> function static variable in new_connection(), which is a file
> static function in dbdimp.ec, that allocates the connection
> number, which is used to generate the connection name. Clearly,
> the code could be revised to pull the connection number from the
> $drh instead, but there'd still be a problem coordinating between
> the different $drh's in the different interpreters.
Yeap.
> This is nasty. Really horridly complex. Is there any mechanism
> for dealing with multiple interpreters provided by Perl?
Here's what I believe (from keeping half an eye on it occasionally):
1/ When a thread is started it's given a clone of the current interpreter.
2/ The degree/extent of cloning is variable (what's included or excluded).
3/ It follows that there's a parent/child relationship among interpreters.
4/ There's a PL_mod_global variable (possibly misspelt, and probably a hash)
that *may* be shared across interpreters and could thus be used to inform
one DBD::Informix of the existence of another etc.
Best to get the latest development release, read the pods, then
ask on perl5-porters. I'd be very grateful if you, or someone,
could do that and report back.
> DBI?
Nope. I've not looked at the issue in any depth yet. Certainly I'd be
very happy to add whatever would help.
> Does each participating DBD writer have to find a mechanism for
> dealing with this?
Only to the extent that they need to for their own reasons.
Many won't need to worry about it at all.
(Even where it is a potential problem you have the option of mandating
that only one thread interacts with DBD::Informix. Not ideal, but workable
for many cases except httpd servers.)
Tim.
