[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