Re: Another feature request...

Haven't you heard? The new catch-phrase is "how does Haskell do it" :)

Tim Bunce wrote:
> Much like my old catch phrase was "How does ODBC do it", my new catch
> phrase is "How does JDBC do it?" - but sadly that doesn't help us much here
> as Java doesn't have native support for coroutines.
> 
> So, my next new catchprase comes into play: "can it be implemented as a
> subclass"?
> 
> Meanwhile, at this point, I'll flag it as a "nice to have feature"
> for us to consider a little further down the road.
> 
> Tim.
> 
> On Fri, Dec 09, 2005 at 02:03:49PM +1100, Adam Kennedy wrote:
> 
>>
>>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