From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: BLOCK_INPUT in compile_pattern_1 Date: Mon, 11 Sep 2006 10:11:23 -0400 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1157983934 27630 80.91.229.2 (11 Sep 2006 14:12:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Sep 2006 14:12:14 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 11 16:12:13 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GMmVs-0005e7-Aw for ged-emacs-devel@m.gmane.org; Mon, 11 Sep 2006 16:11:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMmVr-0006oP-Gi for ged-emacs-devel@m.gmane.org; Mon, 11 Sep 2006 10:11:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMmVS-0006eP-1N for emacs-devel@gnu.org; Mon, 11 Sep 2006 10:11:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMmVR-0006d5-4e for emacs-devel@gnu.org; Mon, 11 Sep 2006 10:11:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMmVQ-0006cv-Qz for emacs-devel@gnu.org; Mon, 11 Sep 2006 10:11:24 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GMmWi-000839-DK for emacs-devel@gnu.org; Mon, 11 Sep 2006 10:12:44 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1GMmVP-0001tV-Kx; Mon, 11 Sep 2006 10:11:23 -0400 Original-To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Sun, 10 Sep 2006 14:53:17 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59679 Archived-At: 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?