Re: [ANNOUNCE]: LuaSocket 2.0.3 RC2

[Sam Roberts <vieuxtech@...>]

2009/11/3 Ignacio Burgueño <ignaciob@inconcertcc.com>:
> Joseph Stewart wrote:
>> Maybe I don't understand the underlying problem the acceptfd patch
>> addresses, but if it's simply a matter of getting the file descriptor
>> from a luasocket object, then you can use the :getfd() function.
>>
>
> Quoting from:
> http://www.net-core.org/39/lua/patching-luasocket-to-make-it-compatible
>
> "It adds a new method “acceptfd” which works just like “accept” but instead
> of returning a socket object it returns  the underlying “file descriptor” (a
> number). A new optional parameter to “socket.tcp()” allows to create a
> socket object from a file descriptor."
>
> So you could accept connections in a given Lua state and process it in a
> different one. Be it by means of using Lanes, LuaProc, or whatever suits
> you.

The above doesn't answer the OP's question of how

fd = ssock:acceptfd()

is different from

fd = ssock:accept():getfd()

It might be that the problem is that the accepted userdata will close
the underlying fd in it's __gc().

If true, acceptfd() might be better replaced with a method of
relinquishing ownership.


I totally support the idea of being able to work with fds in the
luasocket API, particularly so tcp-like userdata can be created from
fds. I would use this for serial devices, for example, which are much
more like sockets than they are like files, so lua's stdio-based io
library works quite poorly with them, despite being able to do
io.open"/dev/ttyWhatever"

Cheers,
Sam