Re: flawed LuaSocket select()/tcp.receive() interaction ?

[lua@...]

* On 2006-11-20 Jerome Vuarand <jerome.vuarand@ubisoft.com> wrote  :

> lua@zevv.nl wrote:
> > >From the manual:
> > 
> >   '*a': reads from the socket until the connection is closed.
> > 
> > This is very different from returning only data that is 
> > available at the time receive is called - receive("*a") will 
> > block until the socket is closed, am I right ?
> 
> Yeah, you're right, I misread the manual. But setting a timeout to 0
> will return whatever bytes are already received.

Ok,

> > Ah, ok - this makes a lot of sense, and this is where I made 
> > my mistake!
> > I am not using socket.select(), but instead I'm passing the 
> > file descriptors returned by socket:getfd() to my own 
> > select() in C code - oblivious of the fact that socket.select 
> > does a bit more then a bare
> > libc-select() call. Did I miss something in the documentation ?
> 
> Mixing a low level and a high level API is never a good idea, unless
> they are designed for that purpose. You can call LuaSocket functions
> from C code easily, thus keeping the ability to use your sockets
> directly from Lua. 

I'm afraid this is not an issue for performance reasons - the main
select() and recv() are handling a handfull of RTP sessions, so I don't
think it's a good idea involve lua code in this process.

> And with non-blocking sockets you will have the behaviour you expect.
> You can roll you own LuaSocket, but if that's just to avoid calling
> socket.settimeout it's not the easiest solution.

Ok, thanks for the help. I'll do some experimentation to see if the
nonblocking behaviour is ok for me, although I think writing a small C
module to do basic handling might be more appropriate because of the
mixing with the C-socket functions.


-- 
:wq
^X^Cy^K^X^C^C^C^C