[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Basic question about LuaSocket and sleeping
- From: mchalkley@...
- Date: Sat, 22 Sep 2012 12:33:05 -0400
Matthew,
Saturday, September 22, 2012, 12:11:19 PM, you wrote:
> Hi,
> On 22 September 2012 16:52, <mchalkley@mail.com> wrote:
>> What I'm really wondering, though, is how socket reads take place. For
>> example, I'm trying to keep my program from using any more system
>> resources than possible because it's a monitoring tool, so it "sleeps"
>> most of the time. How does LuaSocket handle reading sockets if I have
>> it sleeping for 10-15 seconds between iterations (checking the
>> schedule to see if there's anything to do). Does a packet that's
>> received on a socket the program is listening to interrupt the sleep
>> cycle, or what? This is such a basic question, I suppose, that it must
>> be addressed in the documentation somewhere, but I can't find it...
> The function you are looking for is select() (available as
> socket.select()). It is basically a special kind of sleep from which
> the process can be woken up by events on sockets:
> http://w3.impa.br/~diego/software/luasocket/socket.html#select
Thanks! I'll play with a test using select() instead of sleep(), and
learn how that works...
> There are libraries around to abstract select(), Copas is a really
> nice one as far as simple programming goes, but it is designed more
> for servers than clients. It does have the ability to make client
> connections though, and add also timers, with a little more work. I'm
> sure others here have other recommendations too.
>> Maybe I'm just obsessing over something that's "automagic", but one of
>> the reasons I'm learning Lua instead of using Perl or Python, which I
>> already knew, is because of the speed and compactness of Lua. It's
>> pretty cool to see something like what I've got right now run in less
>> than 3 mb of memory (most of the time), and take about 5 seconds of
>> cpu time every 24 hours....
> I worked somewhere once where they ran a critical process on a server.
> It occasionally crashed for one reason or another, so someone wrote a
> small Ruby script to monitor the process and restart it when it
> crashed. The next day both the process and the Ruby script were gone -
> the simple Ruby script having somehow managed to consume all the
> memory on the machine and bring down the service, and itself.
Lol - that's precisely the kind of thing I'm trying to avoid. Thanks
for responding. When I got things a little further along, I was
planning to bug you about Squish and getting it to work with my
project to further improve the compactness and ease of deployment. I
tried it once and couldn't get it to work, but I haven't settled on
the distribution, etc. yet, anyway, so that's probably what needs to
happen next, after I get all the functionality working. (LuaJIT is
also on my radar screen...)
Thanks again,
Mark