[PEAK] PEAK tasks and yield (Was: subscribable/conditional lists)
pf_moore at yahoo.co.uk
Wed Apr 21 09:48:23 EDT 2004
"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!
> worker = binding.Make(events.taskFactory(worker),
> 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.
This signature intentionally left blank
More information about the PEAK