diff options
author | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2012-07-23 07:22:13 +0900 |
---|---|---|
committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2012-07-23 07:22:13 +0900 |
commit | c0792ffe1f4be354f62ff866cf4c7ebb367e70bb (patch) | |
tree | c18ec30ed2c53c0b3feb41a92de2938ee582a764 /open_issues/gnumach_tick.mdwn | |
parent | e9990192bb52a2c6085d4c4d355c6ad9d8bdac67 (diff) | |
parent | a29dec0b89f2961c8af41e6cd851b4ed9c9d28d8 (diff) |
Merge branch 'master' of http://git.savannah.gnu.org/cgit/hurd/web
Diffstat (limited to 'open_issues/gnumach_tick.mdwn')
-rw-r--r-- | open_issues/gnumach_tick.mdwn | 35 |
1 files changed, 35 insertions, 0 deletions
diff --git a/open_issues/gnumach_tick.mdwn b/open_issues/gnumach_tick.mdwn new file mode 100644 index 00000000..eed447f6 --- /dev/null +++ b/open_issues/gnumach_tick.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-05 + + <pinotree> braunr: wrt to mach: it seems to me it ticks every 10ms or so, + it is true? + <braunr> yes + <braunr> and it's not preemptible + <pinotree> braunr: that means a gnumach kernel currently has a maximum + uptime of almost 500 days + <braunr> pinotree: what do you mean ? + <pinotree> there's an int (or uint, i don't remember) variable that keeps + the tick count + <braunr> yes the tick variable should probably be a 64-bits type + <braunr> or a struct + <braunr> but the tick count should only be used for computation on "short" + delays + <braunr> and it should be safe to use it even when it overflows + <braunr> it's not the wall clock + <pinotree> i found that when investigating why the maximum timeout for a + mach_msg is like INT_MAX >> 2 (or 4) or something like that, also due to + the tick count + <braunr> iirc, in linux, they mostly use the lower 32-bits on 32-bits + architecture, updating the 32 upper only when necessary |