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

[lua@...]

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

> lua@zevv.nl 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 [1], 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 [2] 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
> somewhere).

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.

Thank you,


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