Re: Luasocket: poll vs select

[Brian Maher <brian@...>]

AFAIK libuv simply wraps libev so it can have a compatible Windows
API.  So, if you don't care about windows, then a binding to libev
might be what you are looking for.  Your welcome to fork my binding
(and contributions are welcomed!):

  https://github.com/brimworks/lua-ev

I was thinking about trying to fork this project into a wrapper around
libuv, but haven't had time.  Luvit sure looks nice, but it would be
awesome if some of the core components (like integration with libuv)
could be a bit more decoupled (so you can choose which flavor of Lua
to use for example).

Note that the binding to libev was not as trivial as you might expect,
it took me 3 tries to "get it right" (so as to avoid memory leaks
caused by circular callbacks)... a good learning experience :-).

Thanks,
-Brian

On Tue, Feb 21, 2012 at 1:25 PM, Tim Caswell <tim@creationix.com> wrote:
>
> On Tue, Feb 21, 2012 at 10:54 AM, Graham Wakefield <wakefield@mat.ucsb.edu>
> wrote:
>>
>> Luvit is very cool, but a standard lua module binding of libuv would also
>> be very great.
>>
>> I'm working on one, but don't have enough time to make it
>> complete/thorough, just doing the parts that I need... would be happy to
>> collaborate on something more public.
>
>
> That would be great.  Maybe we can share the libuv <-> C bindings since both
> projects will need that.  We just need to decide on a format that both
> projects can use efficiently.  Since libuv is based on callbacks, maybe that
> can be the interface.  It's not hard to map co-routines on top of callback
> based functions at all.
>
>>
>>
>> I agree with Tim that Lua and Libuv are well suited to each other. Libuv
>> is callback-centric (I guess they call that 'evented'), which means that all
>> the heavy work is done in background threads but accessed asynchronously
>> through a single main thread. It applies this approach to a bunch of very
>> useful capabilities (file system, TCP/UDP sockets, timers, pipes, DNS, etc.)
>> for at least the big three platforms (it could be compared to the Apache
>> Portable Runtime in that respect), arguably filling in some of the 'standard
>> library' gaps for desktop Lua.
>>
>> A possibly interesting point: that many of the callbacks are only expected
>> to be called once, especially in the file system API. I found it easy to
>> make these work with yield/resume when called from inside a coroutine, and
>> be blocking calls otherwise; this makes the code extremely easy to read:
>>
>>        local stat = uv.fs_stat(path)                   -- implicit
>> yield/resume
>>        local size = stat.size
>>
>>        local f = assert(uv.fs_open(path, "r")) -- implicit yield/resume
>>        local text = f:read(size)                               -- implicit
>> yield/resume
>>        f:close()
>>     -- implicit yield/resume
>>
>> The :close() call is optional, since __gc will also do this (without a
>> yield/resume).
>>
>> On Feb 21, 2012, at 8:22 AM, Tim Caswell wrote:
>>
>> > If you want to switch to a system with epoll/kqueue (depending on the
>> > arch), libuv is great.  I maintain a version of lua that has libuv at it's
>> > core for single-threaded and highly efficient parallel I/O.  It can easily
>> > handle 500 concurrent users and thousands of requests per second.  The down
>> > side is that it's not stock lua and most existing third-party lua modules
>> > won't work out of the box. (different I/O model, slightly different module
>> > system)  http://luvit.io/
>> >
>> > I don't think this will be easy to integrate with freeswitch since the
>> > luvit binary replaces the lua binary.
>> >
>> > As far as the original question, I'm afraid I am unable to help there.
>> >
>> > On Tue, Feb 21, 2012 at 9:13 AM, Javier Gallart <jgallartm@gmail.com>
>> > wrote:
>> > Hi all
>> >
>> > we are running a freeswitch based application that uses intensively the
>> > Lua XML-RPC library. Everything runs perfectly fine until we reach 12-15
>> > calls/sec, which can be safely assumed to mean to 12-15 http requests/seq.
>> > At that point some of the invocations of xmlrpc.http "call" method fails
>> > with either with "Resource Temporarily unavailable" or "Bad file
>> > descriptor". If we push it a bit harder, freeswitch dies:
>> >
>> > Core was generated by `./freeswitch -nc -ncwait -nonat'.
>> > Program terminated with signal 11, Segmentation fault.
>> > #0  0x00002aaab291dd70 in socket_recv () from
>> > /usr/local/lib/lua/5.1/socket/core.so
>> >
>> > I read here:
>> > http://wiki.voiceworks.pl/display/~pawel/Luasocket+core+dumps+in+socket_waitfd
>> > that usage of poll instead of select  was preferred. I just tried it and in
>> > a test environment it woks perfect, I've been able to reach more than 20
>> > calls/sec without a single failure. However, I'm not really sure of what I'm
>> > doing and I'd like to know if this change could have any side effect. What
>> > do you think?
>> >
>> > Regards
>> >
>> > Javier
>> >
>>
>>
>



-- 
Brian Maher >> Glory to God <<