[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: on the cost of non-blocking LuaSockets
- From: Sean Conner <sean@...>
- Date: Thu, 11 Dec 2014 12:31:28 -0500
It was thus said that the Great Valerio Schiavoni once stated:
> Due to continuous 'timeout' errors returned by the receiving socket (which
> is set to nonblocking, socket:settimeout(0)), the coroutine continuosly
> yields: in this case, is the reception of the data somehow put 'on hold' ?
You don't need to set the socket to non-blocking if you use select just
for reading (and I just checked our codebase at work---I don't set any of
the sockets to nonblocking). All select() does is indicate when a file
descriptor (in your case, a network socket) has received data (ready for
reading), can write data without blocking (ready for writing ) or an
> This happens here:
> The continuous yield/resume of the coroutine associated with the socket is
> apparently very costly.
> Is the yield/resume known to be a costly operation that should be used
> carefully ?
> Isn't there any clean way to have the coroutine associated with the socket
> to somehow keep running in background without being continuously
> interrupted ?
Lua coroutines are not threads as they don't run autonomously but need to
be explicitely scheduled (or resumed). I have sample Lua code that does
this, but it uses my own network  and select  modules, not luasocket
. If you are interested, I can send the code which may help you with
 The semantics for "ready to write" are unituitive (in my opinion)
with select(). For proper use, you have to set the socket for
non-blocking operation, and then when a socket write returns less
bytes written than you wanted, *then* you add the socket to the
"ready for writing" set, and buffer the unsent data. When that
socket is then "ready for writing", you then can write data to the
socket and if all the data is accepted, then you *have* to remove
the socket from the "ready to write" set.
 I didn't care for luasocket's API model.