Re: Another feature request...

On Fri, 2005-12-09 at 14:03 +1100, Adam Kennedy wrote:
>  > 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.

Software Transactional Memory is a composed feature that bundles
elements of semaphores, locks, consistent read, etc, into a convenient
interface.  It is not a technique in itself on Van Neumann machines.

>  > 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.

It is useful at least wherever lazy access to multiple result sets would
be useful.  To be honest co-routines are one of those things that until
you see how simple they make some problems, you don't understand why
they are useful.

Oracle seems to support multiple concurrent selects operating as if they
were all read-only cursors.  Pg, etc, can support this behaviour with
explicit cursors.

> 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...

Yes, probably.

Sam.