Re: [ANNOUNCE]: LuaSocket 2.0.3 RC2

[Nicolas <nicolas@...>]

> Lua function return types are not static, so socket.tcp() could return
> a tcp{master} in the general case, and a tcp{client} if it is passed a
> "serializable socket description". The caller knows if he's passing a
> parameter or not, so checking the return type shouldn't even be
> mandatory.

I know that.
You did not understand what I was saying. *Currently* socket.tcp() takes
no argument and always returns a tcp{master}.
The patch I made makes it do just what you say :)

> I assume you can transport strings through Lindas. At the very least,
> whatever a socket is on Windows (or any other platform) if you have it
> in one thread, you can get it's address in memory, serialize the
> address, send it, have the other thread deserialize the memory
> address, and unreference it. IMHO this doesn't seem like a good
> solution to circumvent Lanes inability to share resources between
> threads.

Yes indeed, or even casting the address itself into an int but
that is not much better.

> The nice part is that it would make the work independent of LuaLanes,
> and eventually compatible with all "multiple-independent-states" Lua
> threading libraries. However I don't know the LuaSocket sources, and
> such an adaptation could mean any amount of work between mere
> adjustments to a complete rewrite.

Probably yes, much more work than I am willing to do ;)
The "best" option seems the passing of the fd/handle pointer directly,
clunky as it may be.