view src/blockinput.h @ 15013:aad88afa6a0c libc-960413 libc-960414 libc-960415 libc-960416 libc-960417 libc-960418 libc-960419 libc-960420 libc-960421 libc-960422 libc-960423 libc-960424 libc-960425 libc-960426 libc-960427 libc-960428 libc-960429 libc-960430 libc-960501 libc-960502 libc-960503 libc-960504 libc-960505 libc-960506 libc-960507 libc-960508 libc-960509 libc-960510 libc-960511 libc-960512 libc-960513 libc-960514 libc-960515 libc-960516 libc-960517 libc-960518 libc-960519 libc-960520

* config.guess: Combine two OSF1 rules. Also recognize field test versions. From [e-mail]. * config.guess (dgux): Use /usr/bin/uname rather than uname, because GNU uname does not support -p. From [e-mail].

/* blockinput.h - interface to blocking complicated interrupt-driven input.
   Copyright (C) 1989, 1993 Free Software Foundation, Inc.

This file is part of GNU Emacs.

GNU Emacs is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs; see the file COPYING.  If not, write to
the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.  */


/* When Emacs is using signal-driven input, the processing of those
   input signals can get pretty hairy.  For example, when Emacs is
   running under X windows, handling an input signal can entail
   retrieving events from the X event queue, or making other X calls.

   If an input signal occurs while Emacs is in the midst of some
   non-reentrant code, and the signal processing invokes that same
   code, we lose.  For example, malloc and the Xlib functions aren't
   usually re-entrant, and both are used by the X input signal handler
   - if we try to process an input signal in the midst of executing
   any of these functions, we'll lose.

   To avoid this, we make the following requirements:

   * Everyone must evaluate BLOCK_INPUT before entering these functions,
   and then call UNBLOCK_INPUT after performing them.  Calls
   BLOCK_INPUT and UNBLOCK_INPUT may be nested.

   * Any complicated interrupt handling code should test
   interrupt_input_blocked, and put off its work until later.  

   * If the interrupt handling code wishes, it may set
   interrupt_input_pending to a non-zero value.  If that flag is set
   when input becomes unblocked, UNBLOCK_INPUT will send a new SIGIO.  */

extern int interrupt_input_blocked;

/* Nonzero means an input interrupt has arrived
   during the current critical section.  */
extern int interrupt_input_pending;

/* Begin critical section. */
#define BLOCK_INPUT (interrupt_input_blocked++)

/* End critical section.

   If doing signal-driven input, and a signal came in when input was
   blocked, reinvoke the signal handler now to deal with it.

   We used to have two possible definitions of this macro - one for
   when SIGIO was #defined, and one for when it wasn't; when SIGIO
   wasn't #defined, we wouldn't bother to check if we should re-invoke
   the signal handler.  But that doesn't work very well; some of the
   files which use this macro don't #include the right files to get
   SIGIO.

   So, we always test interrupt_input_pending now; that's not too
   expensive, and it'll never get set if we don't need to resignal.  */
#define UNBLOCK_INPUT \
  (interrupt_input_blocked--, \
   (interrupt_input_blocked < 0 ? (abort (), 0) : 0), \
   ((interrupt_input_blocked == 0 && interrupt_input_pending != 0) \
    ? (reinvoke_input_signal (), 0) \
    : 0))

#define TOTALLY_UNBLOCK_INPUT (interrupt_input_blocked = 0)
#define UNBLOCK_INPUT_RESIGNAL UNBLOCK_INPUT