BLOCK_INPUT in compile_pattern_1

BLOCK_INPUT in compile_pattern_1

[Stefan Monnier]

Richard, concerning your question:

  /* Doing BLOCK_INPUT here has the effect that
     the debugger won't run if an error occurs.
     Why is BLOCK_INPUT needed here?  */

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.


        Stefan

Re: BLOCK_INPUT in compile_pattern_1

[Richard Stallman]

    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?

Re: BLOCK_INPUT in compile_pattern_1

[Stefan Monnier]

>    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?

I guess so, although to tell you the truth, avoiding such brittle
reasoning (And code) was one of the motivations for my SYNC_INPUT patch, so
now that I've implemented this patch I prefer not to think too much about
what could happen in this or that corner case when SYNC_INPUT is
not used.


        Stefan