lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 [1]) or an
error happened.

> 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 [2] and select [3] modules, not luasocket
[4].  If you are interested, I can send the code which may help you with
your issue.


[1]	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.



[4]	I didn't care for luasocket's API model.