emacs-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]