 |
lua-l archive |
|
|
||
|
---------- Forwarded message ----------
From: Tim Caswell <tim@creationix.com>
To: Lua mailing list <lua-l@lists.lua.org>
Cc:
Date: Tue, 21 Feb 2012 15:25:23 -0600
Subject: Re: Luasocket: poll vs selectOn 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
>