Hi Serge, Jim, all, On 07/12/2011 07:04 PM, Jim Peters wrote: > In this case we're talking about an Iterator. A traditional > non-coroutine implementation of an Iterator would hold state in the > Iterator object and generate new objects to return one by one on > demand, implemented with an internal generate_next() call or similar. > This will run in a single thread. A co-routine or generator type > implementation turns the code inside out, and holds state on its own > private stack (i.e. local variables) instead of inside the Iterator > object. If implemented as a coroutine the iteration will also run > inside a single thread, and the equivalent of the generate_next() call > is a longjmp switch to the coroutine and a longjmp back. This is > comparable to the non-coroutine implementation. However, if the > coroutine is running in a separate thread, then we require the kernel > to schedule a context switch. This HAS to be slower -- at least > that's how it seems to me.
Iterators already exist in Vala, so why not just use them?
(I didn't look in detail at the examples for couroutines and generators, so
if I missed something obvious, sorry.)
Best regards
Christian
--
|------- Dr. Christian Siefkes ------- christ...@siefkes.net -------
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
| Peer Production Everywhere: http://peerconomy.org/wiki/
|---------------------------------- OpenPGP Key ID: 0x346452D8 --
A bug is a test case you haven't written yet.
-- Mark Pilgrim
signature.asc
Description: OpenPGP digital signature
_______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
