From:	Adam Kennedy	Date:	Thu Dec  8 20:03:49 2005
Subject:	Re: Another feature request...

Sam Vilain wrote:
 > On Thu, 2005-12-08 at 23:51 +0000, Tim Bunce wrote:
 >
 >>On Tue, Dec 06, 2005 at 01:57:58PM +1300, Sam Vilain wrote:
 >>
 >>>How about co-operation with coroutines (See the end of S17 in
 >>>pugs/docs/AES) in DBI v2 ?
 >>>
 >>>Of course it would be heavily driver dependent :).  But if there is
 >>>anything that DBI could do to be coro-safe, that would be cool.
 >>
 >>Can you expand on this with some practical examples?
 >
 >
 > How about "simple" to start off with.  This one launches three queries
 > "in parallel".
 >
 >  my $dbh = DBI.connect(...);
 >  $dbh.begin_work;
 >  my @coros;
 >  for (1..3) {
 >     my $coro = coro {
 >         my $sth = $dbh.prepare(...);
 >         $sth.execute;
 >         for =$sth -> $row {
 >             # process result...
 >         }
 >         $sth.finish;
 >     };
 >     $coro.ready;
 >     push @coros, $coro;
 >  }
 >  $_.join foreach @coros;
 >  $dbh.commit;
 >
 > Now, to understand this program, remember that a coroutine is a bit like
 > a thread, but it doesn't need another process or OS thread; instead it
 > uses defined preemption points.  Coroutines don't suck in practical use
 > like OS threads, because no matter how "lightweight" they are because
 > you still need to protect access to all common data structures with
 > locks, semaphores, etc.

Or in Perl 6, with Software Transactional Memory.

 > The preemption points in the above are taken to be; the "join" (which
 > waits for a coro to finish), and all the $dbh and $sth operations.  Of
 > course the Coroutine API is not finished so I made up .join and .ready.
 >
 > If the DBD is capable of handling multiple statements with a single
 > database connection, then it could conceivably multiplex the execution
 > of the blocks as data is returned.  Otherwise, the first one's .prepare
 > or .execute will not return until the lock is freed by the $sth.finish
 > call.  It is not acceptable to open separate database handles, because a
 > transaction is open.  Then again, if the driver doesn't support
 > multiplexing, but supports cursors (and DBIv2 is capable of turning
 > selects into cursors when it needs to), then cursors could be used to
 > allow the parallelism.
 >
 > Does that explain much, or would something "practical" be better?

I would be interested in a real example of where this is useful. I'd 
also like to know if any database in existance supports this, or plans to.

As for implementation (regardless of merit), since the main idea is to 
encapsulate the larger chunks of functionality into Roles, I wouldn't 
imagine it would be that hard to implement some form of 
DBI2::Role::Cororoutine role...

Adam K