[GRASS5] "sync" in scripts

[Glynn Clements]

Hamish wrote:

> > > how portable is it to use the "sync" command in shell scripts?
> > > Currently a couple of scripts that use the netpbm tools use a "sleep
> > > 1" command to wait for the disk write, but sync is more appropriate?
> > 
> > What is the reason for running "sync"?
> > 
> > AFAIK, the only useful reason for calling sync is if you want the
> > following command(s) to run as fast as possible without being slowed
> > down by excessive disk access.
> 
> The problem is that "d.mon stop=PNG" exits before the file is fully
> written?

"d.mon stop=..." exits as soon as it has told the driver to stop. It
doesn't wait until the driver actually stops.

If you want to wait until the driver has finished, I suggest the
following trick:

1. Create a FIFO.
2. Create a background subprocess which attempts to read from the FIFO
before running any commands which are meant to wait until after the
driver has finished.
3. When starting the driver, associate a descriptor with the write end
of the FIFO, e.g. "d.mon start=PNG 3>$fifo".

E.g.

	fifo=$TMPDIR/fifo.$$
	mkfifo $fifo
	( read <$fifo ; do_stuff_with map.png ) &
	d.mon start=PNG 3>$fifo
	# d.*
	d.mon stop=PNG
	rm $fifo

The read will block until the FIFO is closed, which will happen when
the driver terminates.

Alternatively, modify R_kill_driver() so that it doesn't return until
the monitor has terminated (i.e. make it do a blocking read on the
connection).

> When you try to do an immediate 'pngtopnm $out | pnmtojpeg'
> conversion on the output map.png you get error message complaining about
> failing to get magic number or something like that. Running "sync" to
> flush the drive buffer or simply "sleep x" cures the problem.

The only reason why sync has any effect is that it is likely to take
some time to complete, similar to sleep. There is no guarantee that
the file will have been written by the time that sync returns.

sync flushes the OS' buffers to the device; it doesn't have any effect
upon the contents of files as seen by an application, as they are read
from the OS' buffers, not from the device.

-- 
Glynn Clements <glynn at gclements.plus.com>