help-gnu-utils
[Top][All Lists]
Advanced

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

Re: [coreutils] slimmer alternative to sleep command?


From: Ralf Wildenhues
Subject: Re: [coreutils] slimmer alternative to sleep command?
Date: Sun, 25 Jan 2009 12:21:33 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* Chris Jones wrote on Sat, Jan 24, 2009 at 07:33:12PM CET:
> On Sat, Jan 24, 2009 at 12:40:19PM EST, Ralf Wildenhues wrote:
> > * Chris Jones wrote on Sat, Jan 24, 2009 at 06:36:32PM CET:
> > > 
> > > I was wondering if I could avoid the overhead of starting and
> > > terminating the sleep child process by using a different strategy. 
> > 
> > Try not polling, but just waiting for the producer of the data to be
> > ready.  
> 
> Hmm.. I should have given more detail: the data is read from the /proc
> filesystem and is therefore acquired pretty much instantaneously. 

That doesn't answer whether the data arrives once a second, or
irregularly, or sometimes faster/more etc.

> This is why I have to "sleep 1".

I don't see yet where you jump to this conclusion.

Can the inotify stuff be used for /proc?  Note there are both C and
shell APIs for it, and you can still think about performance once your
basic algorithm is sane, i.e., does not poll unnecessarily.

> > Maybe your script can read a token (or the data itself) from a
> > pipe, and the producer write to the pipe?
> 
> As I was desperately looking for a solution, I thought of implementing
> something like this .. set up a dedicated timer daemon and have my
> client scripts communicate with it--signals, pipes, sockets..?
> 
> Apart from the fact that I have little idea how I would write this and
> how long it would take me. :-) the whole idea sounds rather complicated
> and I started thinking there might be a better, more standard way.

Pipes and sockets are pretty standard (depending upon what standard you
are looking at ;-), at least on all systems /proc is usable upon.

> Besides, with this horribly difficult solution and all the additional
> hurdles I'd have to jump, the only thing it would achieve is move the
> initial problem somewhere else.
> 
> Maybe bash is not suitable for this little project?

Choose the algorithm first, with such a small program you can still try
out three languages to realize it in afterwards.

Hope that helps.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]