I am writing output to a file, but I want the buffer to be flushed
each time. What is the Lisp equivalent of fsync? Even something
implementation-dependent would be fine, I am using SBCL.
Tamas
Tamas Papp <······@gmail.com> writes:
> I am writing output to a file, but I want the buffer to be flushed
> each time. What is the Lisp equivalent of fsync? Even something
> implementation-dependent would be fine, I am using SBCL.
FINISH-OUTPUT or FORCE-OUTPUT.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
On 2007-08-25, Pascal Bourguignon <···@informatimago.com> wrote:
> Tamas Papp <······@gmail.com> writes:
>
>> I am writing output to a file, but I want the buffer to be flushed
>> each time. What is the Lisp equivalent of fsync? Even something
>> implementation-dependent would be fine, I am using SBCL.
>
> FINISH-OUTPUT or FORCE-OUTPUT.
It would be nice if there was a de facto standard for Lisps on Unix that
would implement FINISH-OUTPUT as fsync(2), but how many implementations
actually do that?
For portable programs, better assume only that FINISH-OUTPUT and
FORCE-OUTPUT flush the stream's buffer like stdio's fflush(3) does in C.
For fsync(2), use FFI or an implementation-specific interface for it.
David Lichteblau <···········@lichteblau.com> writes:
> On 2007-08-25, Pascal Bourguignon <···@informatimago.com> wrote:
>> Tamas Papp <······@gmail.com> writes:
>>
>>> I am writing output to a file, but I want the buffer to be flushed
>>> each time. What is the Lisp equivalent of fsync? Even something
>>> implementation-dependent would be fine, I am using SBCL.
>>
>> FINISH-OUTPUT or FORCE-OUTPUT.
>
> It would be nice if there was a de facto standard for Lisps on Unix that
> would implement FINISH-OUTPUT as fsync(2), but how many implementations
> actually do that?
None, that I know of, and I believe with good reason. The description
for force-output says that it "attempts to ensure that any buffered
output sent to output-stream has reached its destination ...",
however, no attempt is made to define what "destination" is - is it
the file handle of the stream? Or is it the underlying disk file?
What if there is _no_ file involved, but the output is standard
output, hooked up as a pipe in a series of unix commands piped
together; is the destination the file (or printer output, etc.) at the
end of the series of pipes? If so, how would a program get the
feedback that such an operation is done?
> For portable programs, better assume only that FINISH-OUTPUT and
> FORCE-OUTPUT flush the stream's buffer like stdio's fflush(3) does in C.
Yes; this is the only reasonable _portable_ interpretation of the
spec in this area. Simple-streams has the added support for
encapsulating streams, where if a stream's output-handle is itself a
stream, then a finish-output/force-output might translate into an
equivalent finish-output/force-output to the lower-level stream.
But such a propagation cannot be guaranteed; if the encapulated stream
is not conducive to immediate finishing, then the force/finish
operation would be stopped there (as per the last paragraph of the
description for finish-output/force-output/clear-output).
> For fsync(2), use FFI or an implementation-specific interface for it.
Absolutely.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Tamas Papp <······@gmail.com> writes:
> I am writing output to a file, but I want the buffer to be flushed
> each time. What is the Lisp equivalent of fsync? Even something
> implementation-dependent would be fine, I am using SBCL.
Why do you want the equivalent of fsync? It seems rather heavyweight.
Although at the extreme, if you want to _guarantee_ that your data
reaches its destination, then there are tradeoffs that you have to
decide on, as to how much risk you are willing to take. If you want
absolutely _no_ risks, then by rights you must wait for the backups to
be performed on your system and the backup tapes/cds to be transferred
to a secure vault (obviously, most people don't go quite that far).
If you're just looking for general disk integrity, it would be perhaps
better to just use a journalled filesystem. Or, even more likely, if
you are looking for shared communication between two different
processes, you might use a memory-mapped file and use msync() instead.
The Simple Streams specification (see
http://www.franz.com/support/documentation/8.1/doc/streams.htm)
provides for a memory-mapped file capability. I'm not sure what the
current availability of simple-streams is on SBCL, but I do know that
at least the mapped-file class is implemented for CMUCL. The
mapped-file-simple-stream class (see
http://www.franz.com/support/documentation/8.1/doc/classes/excl/mapped-file-simple-stream.htm)
provides the interface for the synchronization using msync() on unix
systems and FlushViewOfFile on Windows. On the former, force-output
causes the call to be made with MS_ASYNC (non-waiting) and
finish-output causes it to be made with MS_SYNC (the waiting
version). I think anything more drastic than that is overkill and
should be done as a special programming effort.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Tamas Papp <······@gmail.com> writes:
>
>> I am writing output to a file, but I want the buffer to be flushed
>> each time. What is the Lisp equivalent of fsync? Even something
>> implementation-dependent would be fine, I am using SBCL.
>
> Why do you want the equivalent of fsync? It seems rather heavyweight.
> Although at the extreme, if you want to _guarantee_ that your data
> reaches its destination, then there are tradeoffs that you have to
> decide on, as to how much risk you are willing to take. If you want
> absolutely _no_ risks, then by rights you must wait for the backups to
> be performed on your system and the backup tapes/cds to be transferred
> to a secure vault (obviously, most people don't go quite that far).
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.
Tamas
Tamas Papp wrote:
> Duane Rettig <·····@franz.com> 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
Daniel Barlow <···@coruskate.net> writes:
> Tamas Papp wrote:
>> Duane Rettig <·····@franz.com> 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.
Thanks for the clarification, I didn't know the difference.
Tamas