Re: file sync

Tamas Papp wrote:
Duane Rettig <duane@xxxxxxxxx> writes:
Why do you want the equivalent of fsync? It seems rather heavyweight.

I am debugging and application that uses X, and when receiving a bad
request, the application terminates. I am sending debug messages
using (format *stream* "Opening display ~a~%" display), and sometimes
the application dies before the buffer is flushed. (force-output
*stream*) solved the problem well.

At the risk of being charged with sadonecrobestiality[*], I'd be surprised if force-output were calling fsync() there. As Duane said, it's probably just the application-level buffers you need to clear, not the kernel disk io cache. If the application were terminating and immediately causing the whole operating system to crash, that's when you need to worry about it.


-dan

[*] flogging a dead horse
.

Relevant Pages

  • Re: file sync
    ... request, the application terminates. ... the application dies before the buffer is flushed. ... *stream*) solved the problem well. ... surprised if force-output were calling fsyncthere. ...
    (comp.lang.lisp)
  • Re: why the usage of gets() is dangerous.
    ... that is to say one that always terminates the program ... with an error message if the buffer is exceeded. ... You have to make it safe within the guarantees provided by the C ...
    (comp.lang.c)
  • Re: conveyor non-stop
    ... output is accumulated until the program using them either terminates ... or the buffer is filled ... for input and output, so, you cannot force an EOF in the input side ... sub-standard NNTP-gateways just apparently cannot process control ...
    (comp.unix.programmer)
  • Re: why the usage of gets() is dangerous.
    ... that always terminates the program with an error message if the buffer is ... With this device we have a perfectly safe getsfucntion. ... It can only fill the buffer correctly or report that it has been exceeded. ...
    (comp.lang.c)