[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Announcing moonslice luv*, and lhttp_parser
- From: Tim Caswell <tim@...>
- Date: Wed, 10 Oct 2012 16:58:12 -0500
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
>
>