unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Steven Tamm <steventamm@mac.com>
Cc: Piet van Oostrum <piet@cs.uu.nl>, Eli Zaretskii <eliz@gnu.org>,
	emacs-devel@gnu.org
Subject: Re: More info on sporadic OS/X crash
Date: Thu, 29 Apr 2004 15:24:42 -0700	[thread overview]
Message-ID: <031ED742-9A2C-11D8-BE34-00039390AB82@mac.com> (raw)
In-Reply-To: <m3oepa218z.fsf@kfs-l.imdomain.dk>

 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" <piet@cs.uu.nl> writes:
>
>>>>>>> "Eli Zaretskii" <eliz@gnu.org> (EZ) wrote:
>>
>>>> From: "Piet van Oostrum" <piet@cs.uu.nl>
>>>> 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 <storm@cua.dk> http://www.cua.dk
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

  reply	other threads:[~2004-04-29 22:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-15 23:15 More info on sporadic OS/X crash John Wiegley
2004-04-23 11:41 ` John Wiegley
2004-04-24  1:15   ` YAMAMOTO Mitsuharu
2004-04-25 17:49     ` Steven Tamm
2004-04-26 13:15       ` YAMAMOTO Mitsuharu
2004-04-26 16:27         ` Steven Tamm
2004-04-27  9:52           ` YAMAMOTO Mitsuharu
2004-04-27 15:24       ` Piet van Oostrum
2004-04-28  6:37         ` Eli Zaretskii
2004-04-28 11:14           ` Piet van Oostrum
2004-04-28 18:53             ` Eli Zaretskii
2004-04-29 12:10               ` Piet van Oostrum
2004-04-29 16:32                 ` Kim F. Storm
2004-04-29 22:24                   ` Steven Tamm [this message]
2004-04-29 22:25                   ` Piet van Oostrum
2004-05-01 11:32         ` YAMAMOTO Mitsuharu
2004-04-26 18:08     ` John Wiegley
2004-04-27  9:59       ` YAMAMOTO Mitsuharu
2004-04-29 22:08         ` John Wiegley
2004-05-01 11:09           ` YAMAMOTO Mitsuharu
2004-05-07  1:24             ` John Wiegley
2004-05-10  6:02             ` John Wiegley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=031ED742-9A2C-11D8-BE34-00039390AB82@mac.com \
    --to=steventamm@mac.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=piet@cs.uu.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).