At 02:57 PM 7/16/02 +0000, Stas Bekman wrote:
>Perrin Harkins wrote:
>>Hmmm... That could really throw a wrench in things. If you have an
>>object based on a hash, and you share that hash, and you re-bless the
>>object in each thread, does that work? What if the hash contains
>>references to other variables. Do they need to be explicity shared as well?
>That's what I meant. Probably non need for Thread::Pool, at all. use a
>shared datastructure, maintain a list of free and busy items and simply
>hand pointers inside this datastructure to the threads asking for an item.
>e.g.:
>
>package DBI::Pool;
>use threads::shared;
>my @pool : shared;
>sub init {} # pre-populate pool with N connections
>sub get {} # return a ref to $dbh, grow the pool if needed
>sub put {} # move the pointer from the busy list to the free list
Hmmm... as long as you do this _before_ the (Apache) threads get started,
this might work. I still haven't got my mind entirely around what one is
allowed to do, what you can do and is allowed, what you can't do but is
allowed and crashes, and what in principle is possible but you're barred
from because of e.g. prototyping getting in the way.
>won't this work? I guess Perrin is right in respect that the whole item
>needs to be shared (deep-shared). can we have such an attribute/function
>that will automatically traverse the datastructure and share it all? or is
>this the case already with 'shared'?
Good question. I don't think it is deep shared and that's why it probably
doesn't work. The way Thread::Queue::Any (which is the transport medium
for Thread::Pool) handles this, is by serializing any data structure with
Storable, pass that around and deserialize that on the other end.
>Now since we want to have various connections, it can be:
>my %pools : shared;
>where each key is a unique identifier, "compiled" from the dbi connect's
>DSN string and a value is the actual pool.
That's an approach. If you could actually share the $sth objects. About
which I have my doubts.
>BTW, there is no more need for Apache prefix in Apache::DBI, this can be a
>generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
>things like connect_on_init(), but just to build the initial pool when the
>process starts.
DBI::Pool would be ok. But unless I'm wrong about the sharing issues,
you're going to be stuck, at least with this version of Perl, with
serializing between threads.
Liz
