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: Thu, 29 Apr 2004 15:24:42 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <031ED742-9A2C-11D8-BE34-00039390AB82@mac.com> References: <16527.37427.874467.884062@Ordesa.local> <2719-Wed28Apr2004205317+0300-eliz@gnu.org> <16528.61611.555662.935325@Ordesa.local> 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 1083277732 881 80.91.224.253 (29 Apr 2004 22:28:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 29 Apr 2004 22:28:52 +0000 (UTC) Cc: Piet van Oostrum , Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 30 00:28:40 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 1BJK1I-0005zc-00 for ; Fri, 30 Apr 2004 00:28:40 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BJK1I-0006EA-00 for ; Fri, 30 Apr 2004 00:28:40 +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 1BJK0v-00058X-K7 for emacs-devel@quimby.gnus.org; Thu, 29 Apr 2004 18:28:17 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BJJyF-0003zi-MN for emacs-devel@gnu.org; Thu, 29 Apr 2004 18:25:31 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BJJxf-0003kF-Po for emacs-devel@gnu.org; Thu, 29 Apr 2004 18:25:27 -0400 Original-Received: from [17.250.248.47] (helo=smtpout.mac.com) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BJJxf-0003iu-8t; Thu, 29 Apr 2004 18:24:55 -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 i3TMOkZJ024839; Thu, 29 Apr 2004 15:24:46 -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 i3TMOj3Z015268; Thu, 29 Apr 2004 15:24:46 -0700 (PDT) In-Reply-To: Original-To: storm@cua.dk (Kim F. Storm) 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:22387 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22387 From the 10.2 and 10.3 select man pages. Select() should probably have been designed to return the time remaining from the original timeout, if any, by modifying the time value in place. However, it is unlikely this semantic will ever be implemented, as the change would cause source code compatibility problems. In general it is unwise to assume that the timeout value will be unmodified by the select() call, and the caller should reinitialize it on each invocation. However it appears that in the code for xnu-344/bsd/kern/sys_generic.c (which corresponds to 10.2), they actually implemented this change So don't worry about the timeout changing. -Steven On Apr 29, 2004, at 9:32 AM, Kim F. Storm wrote: > "Piet van Oostrum" writes: > >>>>>>> "Eli Zaretskii" (EZ) wrote: >> >>>> From: "Piet van Oostrum" >>>> Date: Wed, 28 Apr 2004 13:14:59 +0200 >>>> >>>> (gdb) frame 1 >>>> #1 0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, >>>> efds=0x0, timeout=0xbfffc770) at mac.c:2787 >>>> 2787 return select(n, rfds, wfds, efds, timeout); >>>> (gdb) print *timeout >>>> $3 = { >>>> tv_sec = 0, >>>> tv_usec = 999996 >>>> } >>>> >>>> So this looks normal. >> >> EZ> Well, yes and no: how come it's 999996 microseconds instead of a >> full >> EZ> second? That is, why don't you see this instead? >> >> EZ> $3 = { >> EZ> tv_sec = 1, >> EZ> tv_usec = 0 >> EZ> } >> >> EZ> This higher frame in the backtrace: >> >>>> #2 0x00119948 in wait_reading_process_input (time_limit=1, >>>> microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311 >> >> EZ> seems to imply that wait_reading_process_input was called to wait >> for >> EZ> 1 second and 0 microseconds, so where from did the small >> inaccuracy >> EZ> creep in? >> >> There is some code just above the select that manipulates the usecs. >> (The ADAPTIVE_READ_BUFFERING stuff). But I think it always makes it a >> multiple of READ_OUTPUT_DELAY_INCREMENT, which this isn't. >> >> Then there's also timer_delay which gets calculated from something >> with the current time in it, so maybe that's it. > > The Linux kernel adjusts the timeout value upon return from select to > contain the amount of time "remaining to the specified timeout". This > is very useful in some situations. > > Maybe OS/X does that too. > > -- > Kim F. Storm http://www.cua.dk > > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/emacs-devel