On Sun, 2011-11-06 at 22:21 +1000, Nick Coghlan wrote:
On Sun, Nov 6, 2011 at 5:20 PM, Ron Adam email@example.com wrote:
What is needed is a different path out (and back) to the coroutine that doesn't interfere with the standard yield behavior. Or as you describe it here.
Did my post of the thread+queue based implementation of a coroutine API design concept not go through? It demonstrated exactly the need for a separate I/O channel independent of the call/return and next/send/throw/yield channels.
I'm looking at it now. BTW the resume method is missing the 'return data' at the end.
Yes, I think it will be useful as a way to figure out the best API.
It looks like the API is almost the same as the generator interface, with different spellings.
What do you think about an inverted generator API?
You almost have that, but the throw is in the thread object, and not reachable from the thread.
Outside generator <--> Inside generator
next() yield .send() .throw()
Inverted generator API
Outside cothread <--> Inside cothread
.resume() suspend() throw()
Where resume works like yield, (yield to cothread), and suspend() works like .send(). Throw() raises an exception at the resume() call, like .throw() raises an exception at the yield in a generator.