emacs-devel
[Top][All Lists]
Advanced

[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





reply via email to

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