lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Attachment: pgpnFxA4ap1em.pgp
Description: PGP signature