[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: flawed LuaSocket select()/tcp.receive() interaction ?
- From: Diego Nehab <diego@...>
- Date: Mon, 20 Nov 2006 14:36:59 -0500 (EST)
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
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
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
See the remark on send()...