* 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
