[PEAK] PEAK tasks and yield (Was: subscribable/conditional lists)

[Paul Moore]

"Phillip J. Eby" <pje at telecommunity.com> writes:

> class Work(binding.Component):
>
>      queue = binding.Make(list)
>      itemsQueued = binding.Make(events.Semaphore)
>
>      def worker(self):
>          while True:
>              yield self.itemsQueued; events.resume()
>              item = self.queue.pop(0)
>              self.itemsQueued.take()   # mine! nobody else can have it!
>              doWork(item)
>
>      worker = binding.Make(events.taskFactory(worker),
>      uponAssembly=True)
>
>      def addWork(self,data):
>          self.queue.append(data)   # put it in the queue, then
>          self.itemsQueued.put()    # let waiting tasks know it's there
>
> Which is just as simple as your version, but more explicit about where
> task switching can or can't take place.

This is something that has bugged me for a while about PEAK tasks. I
can't make any sense of this - clearly the yield/resume is a
conventional construct for doing co-operative multitasking, but it's
completely obscure to me. The original code used the result of
events.resume() where this code doesn't. I see nothing that uses the
yielded value, to help me understand what I should yield.

It probably doesn't help that I don't like co-operative multitasking
as a model. I tend to go for event-driven asynchronous models, or real
threads, both of which feel more straightforward. But I don't see any
support for these models in PEAK (or at least, not in a way that
avoids the need for the yield/resume co-operative machinery).

If there are any pointers to explanatory documentation, or better
still, documentation on how to do "real" multithreading with PEAK,
that would be a great help.

Thanks,
Paul.
-- 
This signature intentionally left blank