[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: alarm_signal_handler is called too frequently
From: |
Kim F. Storm |
Subject: |
Re: alarm_signal_handler is called too frequently |
Date: |
Fri, 05 Nov 2004 13:36:20 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) |
I don't get it either.
Why is it unsafe to Feval with input blocked?
Actually, to me it seems to be safer to do it while input is blocked!
"Jan D." <address@hidden> writes:
> I made my question very unclear, I'll try again. Sorry if this is
> obvious for others, but I just don't understand.
>
> Say we have three functions, aL, bL and cL, all written in Lisp (hence
> the L). Now, obviously aL calling bL calling cL is safe (<-- denotes
> return, not cL calls bL).
>
> 1:
>
> aL bL cL
> | --> | |
> | | --> |
> | | <-- |
> | <-- | |
>
> If we replace bL with code in C instead, is this safe?
>
> 2:
>
> aL bC cL
> | --> | |
> | | --> |
> | | <-- |
> | <-- | |
>
> I think it must be, there are places in Emacs where C code calls Lisp
> functions. Say now that bC calls cL within BLOCK/UNBLOCK_INPUT:
>
> 3:
>
> aL bC cL
> | --> | |
> | BLOCK |
> | | --> |
> | | <-- |
> | UNBLOCK |
> | <-- | |
>
> Why is this unsafe, if 2 was safe (if indeed it is)? It is not as
> though the signal handler is calling Lisp code, that is obviously
> unsafe. But when a dialog or popup menu is popped up, the signal
> handler is not involved in processing X events, it is all done inside
> bC.
>
> I'm sorry if this is a stupid question, but I just don't get it.
>
> Jan D.
>
--
Kim F. Storm <address@hidden> http://www.cua.dk