[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-trunk-diffs] Changes to emacs/src/sysdep.c
From: |
Stefan Monnier |
Subject: |
Re: [Emacs-trunk-diffs] Changes to emacs/src/sysdep.c |
Date: |
Mon, 29 Nov 2004 09:31:00 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) |
> Hmm... what happens if you hit C-g while writing a file?
> Before your change, nothing, I believe.
Clearly, that's not the case. C-g during the `write' (or at any other time
for that matter) would cause a signal-handler to be called that processed
the input. This might either do a longjmp or just set quit-flag.
> That code was not interruptible with quit. It would write all the data,
> and the quit would occur afterward. Emacs might get confused as a result
> of quitting inside the middle of the Lisp code to save the buffer, but at
> least the file contents would not be truncated
BTW, is a 2MB file is currently written with a single call to `write'?
> How does Emacs prevent truncation in the normal code?
> I am not sure which code "the normal code" refers to,
> but the way this code was written before, there was no QUIT check
> during the actual writing of the data into the file.
> So QUIT could never cause truncation.
So you're saying that the signal handler just sets quit-flag rather than
calling longjmp. Hmmm.... I guess that makes sense.
> Being able to interrupt a write if it's blocking for a long time (like
> write to an NFS server that's down).
> That is indeed desirable, so I think we have a problem of choosing
> between two kinds of lossage.
Well, we can at least revert to the previous behavior while still make
SYNC_INPUT behave somewhat like non-SYNC_INPUT by replacing QUIT with:
if (interrupt_input_pending)
handle_async_input ();
which is the part of QUIT I actually need there.
> I wish I could remember more clearly what sort of problems could occur if
> quitting could truncate a file.
It's pretty obvious: you end up with a broken file. Maybe there's some
other effect, but that one is bad enough already.
> Maybe we could get the best of both worlds if we set it up so that
> quit can occur inside emacs_write only if it has been sitting there
> for 30 seconds or more since the last data it succeeded in writing.
> That way, users could quit in the case of the dead NFS server,
> but in all ordinary cases the quit would still be delayed until
> after Fwrite_file has finished.
I always felt like there should be a way to force an immediate_quit, not
only is `write'. Maybe by hitting C-g three times in a row or something
like that. Or maybe if you haven't hit anything else than C-g in the last
N seconds and the first C-g is still not processed.
Stefan