emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: usr1-signal, usr2-signal, etc.


From: Kim F. Storm
Subject: Re: usr1-signal, usr2-signal, etc.
Date: Tue, 05 Dec 2006 23:51:03 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

David Kastrup <address@hidden> writes:

> YAMAMOTO Mitsuharu <address@hidden> writes:
>
>>>>>>> On Mon, 04 Dec 2006 14:08:09 +0100, address@hidden (Kim F. Storm) said:
>>
>>>> Currently we only have usr1 and usr2 signals, but if we add more
>>>> (the "etc") later, this would be a cleaner interface for such
>>>> extensions.
>>
>>> For example, we could handle SIGTERM, SIGHUP, and SIGQUIT like this
>>> to allow a user to handle those signals in some other way:
>>
>> I'm concerned about the case that kbd_buffer_store_event_hold is
>> called from the signal-handler context while it is also executed in
>> the normal context.  This has already existed for SIGUSR1 and SIGUSR2
>> before your change, though.
>
> SIGUSR1 and SIGUSR2 are, IIRC, new in Emacs 22.  So we have no "nobody
> complained about that before" reason for allowing problems in that
> manner.

They have been there (in some form) since 1997.
Whether anybody actually used them is another thing.

AFAICS, kbd_buffer_store_event[_hold] is usually called inside
BLOCK_INPUT, but there may be a few places where this is not the case,
notably in keyboard.c (and in the signal handler).  

Would someone pls. check [and fix] this??  One way could be to abort in
kbd_buffer_store_event_hold if called without input blocked.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

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