|
From: | Jan D. |
Subject: | Re: Possible bug in xfns.c |
Date: | Sat, 26 Feb 2005 16:37:12 +0100 |
2005-02-26 kl. 15.47 skrev David Kastrup:
Throwing a signal restores interrupt_input_blocked to the state of the recording of the stack frame.
How does it do that? I can't find that in the code. I assumed record_unwind_protect did just that, recorded one unwind action to take.
In xfns.c, line 5207, we have a BLOCK_INPUT. In line 5283 we haverecord_unwind_protect (clean_up_file_dialog, make_save_value (dialog, 0));That means that clean_up_file_dialog will get called in case of an abort, and x_file_dialog will return with the value of interrupt_input_blocked increased by one as opposed to the time of the call.
I'm not sure what you mean by an abort. The only code that does something like that is the Fsignal and the unbind_to after the UNBLOCK_INPUT. Are you saying that
BLOCK_INPUT; ... record_unwind_protect() ... UNBLOCK_INPUT; unbind_to();will make interrupt_input_blocked have a value of 1 after the unbind_to (assuming it was 0 before BLOCK_INPUT and no code in ... throws)?
Shouldn't record_unwind_protect be enclosed with UNBLOCK_INPUT/BLOCK_INPUT?
That wouldn't be correct, but we could move it before the first BLOCK_INPUT.
Jan D.
[Prev in Thread] | Current Thread | [Next in Thread] |