[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: flawed LuaSocket select()/tcp.receive() interaction ?
- From: lua@...
- Date: Mon, 20 Nov 2006 19:35:48 +0100
* On 2006-11-20 Jerome Vuarand <email@example.com> wrote :
> firstname.lastname@example.org wrote:
> > So, what do I need to do to handle this properly ? Is there a
> > way to make tcp.receive() have the same behaviour as my
> > libc's receive(), that is
> > - don't receive any more then the requested amount of bytes from the
> > socket, and leave the rest pending so select() will notice there's
> > still data waiting to be read.
> > - also return when fewer then the requested amount of bytes are
> > received, returning both the data and it's size
> According to the doc of receive in LuaSocket , you can pass "*a" as a
> pattern to read all the data available in the socket.
>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 ?
> Also socket.select  should tell if characters are available for
> reading, so it should return any socket that has unread buffered data,
> even if no socket actually received data (though there may be a bug
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 ?
My lua code is part of a bigger application where the select() is
watching file descriptors for both lua and C code, so that is the reason
I am not using socket.select()
So this seems to solve the riddle - I think the easiest solution for me
would be to write a lightweight version of luaSocket myself that maps
straight on the libc socket calls.