On Sat, Mar 01, 2003 at 11:29:46AM +1100, Stas Bekman wrote: > Tim Bunce wrote: > > >It dawned on me early this morning that we hadn't been quite on the > >same page thus far... > > > >I'd been presuming the existance of a 'pool management thread' that > >would manage a pool of real dbh's from which it would 'borrow' the > >imp data to 'loan' to other threads requesting connections. > > You have never said that (or I've misread you).
No problem. I hadn't said it explicitly, but it was implicit in some of the comments I'd made and was probably why we were talking at cross-purposes for a while. > >I now realize that the pool is a passive data object and is manipulated > >directly by the requesting threads. In that scenario the 'thing' to > >put into the pool is just the copy of the imp data structure. > > That's exactly how it's implemented now. The only must thing is that the > passive object is created in the parent thread and it's marked as "shared" > between all other threads. The pool, right. > I'm not following your last paras. This is how I see it (and how I > implemented it). > > The pool stores passive objects. This pool can be manipulated by any thread > (with proper mutex locking). > > 1. The pool can act as a library, where objects are borrowed (moved from > the free list to the busy list) and then returned (moved from busy list to > the free list) > > 2. The pool can act as a shop which sells objects (objects are removed from > the free list) and which buys the objects back (at the same price!) > (objects are placed on the free list). In this scenario there is no busy > list, as the shop manages only the inventory of the items it has for sale > and doesn't care about items that were purchased. > > #1 pros: > - we know how many total connections are open at any given moment > - if the thread dies and we have GC we can recover the connection > - we can free() the pool memory cleanly (since we control all the memory > that was allocated) > > #1 cons: > ??? > > #2 pros: > - no need to manage used connections (simpler pool management/a bit faster?) > > #2 cons: > - we don't know how many total connections are open at any given moment > - if the thread unexpectedly dies, we need to figure out how to free() the > memory allocated for the item. > > Anything else I've missed? You mention memory management a couple of times and that might be an area we need to talk some more about... see below. > Are we on the same page? I don't see any blood, so I guess we aren't. I think so. I'd go for #1. I think the pros for #2 are insignificant. Now, back to memory management... As I've mentioned recently, I figure the 'thing' that's placed into the pool is a scalar string that holds a copy of the entire imp data structure. Doing that, rather than passing an integer pointer around, means we avoid issues over which interpreter owns and frees that memory. That just leaves two other related issues... a. How database API data gets cleaned up. b. Who (which interpreter) owns and frees any SVs _within_ the imp data. The best way to handle (a) would be to create a new dbh using the imp data and then let the dbh get destroyed 'normally' (not pass the imp data back to the pool). For (b) we may be able to duck the issue to a certain extent because all we're really trying to pass around is the pointers from the database API. There should be no need to use any SV pointers. On the other hand, any SVs need to get freed at some point. Only the driver know where they are so the driver has to be involved. Seems like the $dbh->take_imp_data method will need driver involvement to 'cleanse' the imp data by freeing everything not essential to the connection - and hopefully that'll include all the SVs. If SVs are required, for some reason, can they be made shared, or replaced with a shared copy? (My perl threads api knowledge is a bit rusty.) Tim.
