Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: compile directly into a .zip/.jar file? Date: Tue, 15 Apr 2014 12:51:43 +0000 (UTC) Organization: A noiseless patient Spider Lines: 48 Message-ID: References: <1l96oa6aew63h$.1wt64t9w3vv91.dlg@40tude.net> <534ad197$0$301$14726298@news.sunsite.dk> <534c8e5e$0$297$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 15 Apr 2014 12:51:43 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="12206"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xExtuU2qb+nq2XetXxN6C6D2ZOe21fWE=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:HR5/T0Ot9JPrBvd03bCgI8dhMts= Xref: csiph.com comp.lang.java.programmer:28091 On Mon, 14 Apr 2014 21:41:50 -0400, Arne Vajhøj wrote: > On 4/13/2014 6:52 PM, Andreas Leitgeb wrote: >> Arne Vajhøj wrote: >>> If the goal is better performance, >> >> It's not like I wanted to squeeze another microsecond out of the >> compile time, but more like trying to bypass some brake, that the >> system has slammed full on for no good reason. >> >>> But with todays OS/file system caches and disk caches - likely in >>> write back mode, then writing those class files to disk may not cause >>> them to be actually written to the rotating plates before long after >>> the process is completed from user perspective. >> >> Unless, maybe, the system believes that a file write/delete isn't done >> until it's physically on the disk and some logs on another... Kind of >> like some sync-flag was set. (maybe it even is - hardcoded) > > That is how it always was in the old days. > AFAIK Unices have traditionally only automatically flushed buffers to disk in three circumstances: (1) if they run out of space in RAM, (2) when a process terminates all buffers get flushed and (3) output buffers are flushed if they haven't been written to for some time and contain unflushed data. Apart from that you can, of course, always call fflush() whenever the process logic requires, e.g. if a process periodically records a restartable checkpoint, it would probably flush buffers for all open files as part of recording the checkpoint. Its sometimes necessary, too, to flush stdout/stderr if the text is prompting for input read from stdin. In general this applies to Linux, and probably also to BSD and derivatives. Other OSen may do things differently, e.g. OS/9, the real-time OS, writes blocks as soon as they are complete and when a file is closed, updating the file and disk management meta-data at the same time. This is deliberate: although it makes i/o a lot slower, its very rare indeed to to loose any data or to see a corrupt file in an OS/9 system unless you're using a dodgy disk. Not doing much of the above is a main reason for FAT filing systems to be relatively fragile. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |