lua-users home
lua-l archive

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


On Wed, Oct 10, 2012 at 3:57 PM, Richard Hundt <richardhundt@gmail.com> wrote:
>>
>>> *I know Richard Hundt beat me to the "luv" name, and one of us will
>>> rename if it becomes a problem.  Personally I think his project is
>>> more than just libuv bindings since it adds 0mq integration and a
>>> fancy coroutine based interface on top.
>>
>> yes, please get this sorted out while both libraries are young.
>
>
> I'm renaming mine.
>
> However, ØMQ aside, why does the presence of a coroutine scheduler on top contribute to it being "more than just libuv bindings"? We have a choice between doing lua_call to call into the VM when a callback fires, or using lua_resume instead: Lua has coroutines, why not use them?
>
> I guess I'm one of these guys who's trying to save the world from callback-based reactor stuff, because he believes that it leads to code that's hard to reason about; that it's inherently bad for you, and for the environment.


I just now got this message in my inbox.  How strange.

Richard I just realized I might sound aggressive or offensive and
apologize.  I think your project is great.  I didn't realize that you
could skip the callback entirely by doing the resume from C code.  I
had read that coroutines from C had nasty edge cases in stock Lua.

Also I'm one of those people who has written callback based code for
years and sees nothing wrong with it.  I am aware that others don't
like it, so my continuable/futures style was my compromise.

Even if we won't be able to collaborate on the libuv bindings, I
wonder if apps written in my "web" style will be able to run on both
systems.

>
> Fortunately it's not hard using this pattern:
>
>   function coro_io:read()
>      local data
>      local curr = coroutine.running()
>      ev_io:on_read(function(...)
>         data = ...
>         scheduler:enqueue(curr) -- back in the queue
>         curr = nil
>      end)
>      while curr do -- avoid spurious wake-ups
>         coroutine.yield()
>      end
>      return data
>   end)
>
> combined with some scheduler:
>
>   scheduler:run()
>
> Which runs all pending coroutines then calls a stepping function of your event loop (uv_run_once() for libuv, but most have them) as long as there are no coroutines to schedule.
>
> I just did it in messy C with a cleverly disguised `scheduler:run()` call ;)
>
> Anyway, as I said. I'll rename mine. Just need to get some refactoring out of the way first.
>
> Cheers,
> Richard
>
>