Sender: nate AT cartsys DOT com
Message-ID: <35BD5A3D.3B5C56E1@cartsys.com>
Date: Mon, 27 Jul 1998 21:57:33 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
MIME-Version: 1.0
To: Martin Str|mberg <ams AT ludd DOT luth DOT se>
CC: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
        DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject: Re: A call to `sync' inside `spawn'
References: <199807271748 DOT TAA29763 AT father DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Martin Str|mberg wrote:
> 
> According to Eli Zaretskii:
> >
> > On Sun, 26 Jul 1998, Martin Str|mberg wrote:
> >
> > > I suppose that there is no way to flush the _write_ cache and not the
> > > read cache?
> 
> [Klippa, klapp, kluppit DOZE mess.]
> 
> > In any case, the call to `sync' before running a child program doesn't
> > even need to flush the write cache.  It just needs to make sure output
> > to the same file/device doesn't appear out-of-order, for which the DOS
> > CommitFile function is enough.  IMHO, this is simply a DOS bug (it
> > should have done that in our stead, inside its Exec function) which we
> > are working around.  I can hardly believe any Unix box calls `sync',
> > since the `sync' system call is typically prohibitively expensive on
> > Unix (it takes several seconds even on fast machines).
> 
> No, I was thinking the sync call. It's such a waste to forget the read
> cache, when it's not necessary.
> 
> And sync on my machine (Linux) doesn't take several seconds. Less than
> one, actually, and it's not idle.

I think it will depend on what the system is doing.  On Unix, it's
traditional for the `update' daemon to call `sync' every 30 seconds or
so, so if it's been fairly idle since then, there won't be much to do. 
If the system is heavily loaded, on the other hand (try `cd
/usr/src/linux; make -j 9999 &'), it will be slow.
-- 

Nate Eldredge
nate AT cartsys DOT com