Re: Announcing moonslice luv*, and lhttp_parser

[Richard Hundt <richardhundt@...>]

> 
>> *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.

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