On Sunday 21 August 2005 1:56 pm, Chris Pressey wrote: > > i don't think so. i've sometimes tried some weird 'coroutines within > > coroutines' yielded at several levels with mostly expected results. > > for example, in Xavante the main dispatcher is a coroutine-based > > iterator. > > Perhaps I'm confused; I thought the dispatcher in Xavante *was* Copas? we're missing some good definitions to help the dialogue: Copas is wha i'd call a "scheduler". in kernel-talk the scheduler is the one that arbitrates between processes analogous (but at a different level) to Copas' work. what i call a "dispatcher" in Xavante is the code that parses the HTTP request and picks the appropriate handler to manage it. the main one is a "for p in path_iterator (path) do...." using a coroutine iterator. (i love the control inversion for iterators!) > After studying the internals of Copas for a bit more, I've come to see > what my code is violating. (As nice as it can be for Copas to hide the > details of coroutines from its users, it definately has a downside :) yep, the main point to remember is to make sure you're yield()ing to the correct resume(). > Spelling it out like this, it's almost painfully obvious: there are two > seperate coroutine.yield()'s with two different purposes in the same > coroutine. Sometimes, like when it gets good data, it will yield data > to its resumer; but on other conditions, like a timeout, it will yield > the socket itself, thinking that the resumer is the dispatcher - when > actually it's not, it's my handler. hum... i can't argue with that.... but that would mean my first implementation of coroutine-persistence-handlers shouldn't work! i'll have to review it -- Javier
Attachment:
pgp9FwAcK8XYq.pgp
Description: PGP signature