yield ( was Application extension API suggestions )

["John Dunn" <John_Dunn@...>]

> Enter coroutines:
> 
> local wrap, yield = coroutine.wrap, coroutine.yield   -- locals are
> easier, safer... and faster too !
> 
> Timer.addEventHandler(wrap(function()
>   while true do
>     for count = 1, 10 do  -- indeed "count to 10 over and over again"
>       -- ...
>       yield()
>     end
>   end
> end))
> 
> Here the control structures are very natural, even though the 
> function is actually executed by slices. Also, the scope of 
> count is now as narrow as possible. For these reasons, I 
> would favour the use of coroutines in such a setup.

After thinking about this a little more I have some questions. I assume
when one yields(), at some point it's assumed it will be resumed?

It seems like there's ( at least ) 2 ways to approach the handler-

1. The handler is called via lua_pcall(). The handler function is
expected to return to give control back to the app. If the function
doesn't return at some point it's likely bad things will happen.

2. The handler is initially called with lua_newthread() but subsequent
calls are via lua_resume. The handler is expected to return control to
the app via a call to yield(). If the function doesn't call yield at
some point it's likely bad things will happen.

Is one approach more lua-y ( lua-ish? )? Coming from a C++ background
(1) seems more straightforward but it does seem like (2) is more
powerful.

John