Re: Luasocket: poll vs select

[Graham Wakefield <wakefield@...>]

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.

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
>