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

[Diego Nehab <diego@...>]

Hi,

> Yes, I know that page - can you please specify what was
> not clear about my question, this will surely help me ask
> smarter ones next time.

I meant the fact your subject claims there is a flaw
somewhere, rather than considering the possibility there is
a problem with your understanding of the issue.

I am obviously overreacting here. To protect yourself from
this kind of reaction, simply approach the potential
problems in a more subtle way.

> No, I'm afraid this is not the case. From the linux man
> page of recv: "The receive calls normally return any data
> available, up to the requested amount, rather than waiting
> for receipt of the full amount requested."

You are right. Even the POSIX standard agrees with you (man
pages are not reliable enough in multi-platform
applications).  The problem is with send(). This is why I
set sockets to non-blocking.

> > Yes, it will. There is code there to specifically handle
> > this case. If you have a sample that doesn't work, this
> > is a bug and it must be fixed. Are you just assuming that
> > it doesn't work?
>
> No, I tested. If it is of any help I can could make some
> minimal examples in both C and Lua to show the different
> behaviour

I guess this has been sorted out already.

> > > - also return when fewer then the requested amount of
> > > bytes are received, returning both the data and it's
> > > size
> >
> > This is not the standard behavior in C either.  You have
> > to put the socket in non-blocking mode. To do that in
> > LuaSocket, simply set the timeout to 0.
>
> Nonblocking mode should never be necassery when using
> select(), because of the proper behaviour of recv() as I
> described above.

See the remark on send()...

[]s,
Diego.