Sorry for the confusion! This is tough. Steve & I were mostly rambling,
and at least I was posting a mixture of things I've done, speculation,
and half-formed pseudo-proposals ... & in no particular order.
The actual problem is that the example I posted was _too_ simple <wink>:
it didn't show why all the supporting hair got invented to begin with,
only that it worked in a simple example.
BTW, the real point of the "cloning" in the examples was to supply each
active object its own set of (conceptual) local variables, and your
Generator class does that automatically. In other words, the Generator
class does all the "cloning" I _usually_ need even without the .clone
method.
> ...
> You don't give up easily don't you :-)
It depends. Challenge my stubbornness like this again, & I'll resume
whining about strings <wink>.
> ... Note that you can't rely on __del__() being called since the
> producer still has a reference to the object, so I added a kill()
> method.
Thanks for clearing that up! Of course I agree, now that I've been
kicked in the butt with the obvious.
> ...
> If you think of get() as read(), you can surely think of put() as
> write(), and then surely you can think of tons of applications for
> this -- it's so natural to structure a big generator as a set of
> subroutines. (Haven't any real examples yet -- sorry.)
No problem -- I'm sure they'll pop up. I'm just afraid they'll turn out
to be useful in ways that require the full power of the thread
implementation. Too soon to say!
> ...
> # Generator implementation using threads
BTW, has anyone built Python with vanilla POSIX pthreads? I see there
are some relevant #ifdef's in the relevant modules, but the Makefiles
don't seem to cater to the possibility directly.
Haven't tried it yet, just wondering whether someone already has.
echoing-the-eternal-question-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp