[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: flawed LuaSocket select()/tcp.receive() interaction ?
- From: lua@...
- Date: Mon, 20 Nov 2006 20:12:43 +0100
* On 2006-11-20 Jerome Vuarand <email@example.com> wrote :
> firstname.lastname@example.org 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.
> > 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.