[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: BLOCK_INPUT in compile_pattern_1
From: |
Richard Stallman |
Subject: |
Re: BLOCK_INPUT in compile_pattern_1 |
Date: |
Mon, 11 Sep 2006 10:11:23 -0400 |
I don't have a firm answer, but I suspect that it may have been due to the
fact that re_compile_pattern may call `malloc'. And since our
signal-handling routines can also call `malloc' (unless we use SYNC_INPUT),
we have to be careful to BLOCK_INPUT around any direct or indirect call
to malloc.
I think you are right, because I found this comment:
Here's another reason to avoid allocation: Emacs
processes input from X in a signal handler; processing X input may
call malloc; if input arrives while a matching routine is calling
malloc, then we're scrod. But Emacs can't just block input while
calling matching routines; then we don't notice interrupts when
they come in. So, Emacs blocks input around all regexp calls
except the matching calls, which it leaves unprotected, in the
faith that they will not malloc. */
But I think that reason is obsolete. Nowadays regex.c defines malloc
as a macro to expand into xmalloc, which does BLOCK_INPUT.
So I think that that BLOCK_INPUT call is obsolete,
and that so is MATCH_MAY_ALLOCATE.
Do you think this is correct?