all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* BLOCK_INPUT in compile_pattern_1
@ 2006-09-10 18:53 Stefan Monnier
  2006-09-11 14:11 ` Richard Stallman
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2006-09-10 18:53 UTC (permalink / raw)
  Cc: emacs-devel


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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: BLOCK_INPUT in compile_pattern_1
  2006-09-10 18:53 BLOCK_INPUT in compile_pattern_1 Stefan Monnier
@ 2006-09-11 14:11 ` Richard Stallman
  2006-09-11 14:28   ` Stefan Monnier
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Stallman @ 2006-09-11 14:11 UTC (permalink / raw)
  Cc: emacs-devel

    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?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: BLOCK_INPUT in compile_pattern_1
  2006-09-11 14:11 ` Richard Stallman
@ 2006-09-11 14:28   ` Stefan Monnier
  0 siblings, 0 replies; 3+ messages in thread
From: Stefan Monnier @ 2006-09-11 14:28 UTC (permalink / raw)
  Cc: emacs-devel

>    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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-09-11 14:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-10 18:53 BLOCK_INPUT in compile_pattern_1 Stefan Monnier
2006-09-11 14:11 ` Richard Stallman
2006-09-11 14:28   ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.