From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Steven Tamm Newsgroups: gmane.emacs.devel Subject: Re: More info on sporadic OS/X crash Date: Mon, 26 Apr 2004 09:27:52 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040426.221527.198676483.mituharu@math.s.chiba-u.ac.jp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1082999430 1266 80.91.224.253 (26 Apr 2004 17:10:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Apr 2004 17:10:30 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Apr 26 19:10:22 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BI9cc-0003vq-00 for ; Mon, 26 Apr 2004 19:10:22 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BI9cb-0004l8-00 for ; Mon, 26 Apr 2004 19:10:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BI9MY-0007Tu-E7 for emacs-devel@quimby.gnus.org; Mon, 26 Apr 2004 12:53:46 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BI9F2-0006Ho-Pq for emacs-devel@gnu.org; Mon, 26 Apr 2004 12:46:00 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BI8zS-0001ua-8D for emacs-devel@gnu.org; Mon, 26 Apr 2004 12:30:26 -0400 Original-Received: from [17.250.248.84] (helo=smtpout.mac.com) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BI8xZ-0001Kz-2O for emacs-devel@gnu.org; Mon, 26 Apr 2004 12:27:57 -0400 Original-Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i3QGRuaD017628; Mon, 26 Apr 2004 09:27:56 -0700 (PDT) Original-Received: from [10.0.1.201] (c-24-5-11-73.client.comcast.net [24.5.11.73]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id i3QGRt3Z027679; Mon, 26 Apr 2004 09:27:55 -0700 (PDT) In-Reply-To: <20040426.221527.198676483.mituharu@math.s.chiba-u.ac.jp> Original-To: YAMAMOTO Mitsuharu X-Mailer: Apple Mail (2.613) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22186 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22186 The reason for all of the polling nonsense in the first place is to deal with runaway processes. For example, compile this program and run it using (shell-command) or M-! #include int main(int argc, char** argv) { while (1) ; } If C-g interrupts it, then it still works. With carbon emacs as it is now, this works. The other example would be to setup an infinite loop *inside* emacs; i.e. not as a subprocesses. The simplest being: (while t t) Right now, with Carbon Emacs, this causes the beachball of death and C-g does nothing. This is why the "mac_check_for_quit_char" is peppered throughout the code; but in this instance it doesn't work. Of course if you send a SIGINT to the process it works... And (while t (eval t)), a more realistic example, C-g does work. I filed a bug with Apple a year and a half ago asking if an application could setup a key that causes a signal, but I can't seem to find the resolution for it. -Steven On Apr 26, 2004, at 6:15 AM, YAMAMOTO Mitsuharu wrote: >>>>>> On Sun, 25 Apr 2004 10:49:07 -0700, Steven Tamm >>>>>> said: > >> The patch seemed to make sense to be, except for the FD_CLR >> (i.e. the bug in select from 10.1) I forgot to ask, have you tried >> that patch on 10.2 or just 10.3? > > I just tried the patch on both 10.1.5 and 10.2.8, but I could not find > any problems by a few tests on subprocesses. If you have a specific > example, maybe I can test it. > >> And with the non-carbon build? > > For the X11 build, fd 0 is excluded from input_wait_mask with > add_keyboard_wait_descriptor in x_term_init. For the Carbon build, fd > 0 is never consulted in sys_select (in mac.c with the patch), but the > window event queue is consulted instead. > > A comment in mac.c says: > > When Emacs is started from the Finder, SELECT always immediately > returns as if input is present when file descriptor 0 is polled for > input. Strangely, when Emacs is run as a GUI application from the > command line, it blocks in the same situation. This `wrapper' of > the system call SELECT corrects this discrepancy. > > According to the output of lsof, fd 0 is bound to /dev/null for the > former case, whereas it is bound to the tty from which Emacs is > invoked for the latter case. That would explain the above phenomena. > > YAMAMOTO Mitsuharu > mituharu@math.s.chiba-u.ac.jp