From owner-cvs-src@FreeBSD.ORG Fri Oct 21 20:40:07 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57D1C16A41F; Fri, 21 Oct 2005 20:40:07 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDC4243D45; Fri, 21 Oct 2005 20:40:06 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j9LKe5An088347; Fri, 21 Oct 2005 13:40:05 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <31753.1129924404@critter.freebsd.dk> References: <31753.1129924404@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <440C26C7-38DF-45C8-A36C-31BB75454FE7@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 21 Oct 2005 13:40:04 -0700 To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.734) Cc: src-committers@FreeBSD.org, Andre Oppermann , Bruce Evans , cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Andre Oppermann Subject: Re: Timekeeping [Was: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c] X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 20:40:07 -0000 On Oct 21, 2005, at 12:53 PM, Poul-Henning Kamp wrote: > In message <01DFB595-5279-4D3A-BEDA-5F0285E9519B@xcllnt.net>, > Marcel Moolenaar > writes: > > >>> I think we need the definition to consider if (process- ?)state is >>> retained while the system is unconcious or not. >>> >> >> I'm not sure. I think that might be what makes the definition >> complex. >> > > Actually I don't think it does, it simplifies it. > > If a process survives across the "unconcious" period, then it follows > that CLOCK_MONOTONIC cannot be reset to zero in relation to the > unconcious period. Yes, true. But technically speaking, this has no inherent relation to uptime other than in our implementation. It should be perfectly valid to preserve the value of CLOCK_MONOTONIC and not reset it across (some) non-operational states while resetting uptime for those states. Processes just need to be informed about a reset in uptime when they are sensitive to it (and let the system know about it). > select(...., {3m0s}) > suspend > [ 2 minutes pass ] > resume > > When does select time out ? > > One minute after the resume ? > > Three minutes after the resume ? > > Right after the resume with a special errno ? Ah, yes. These are the interesting questions. One possible attempt to solve the problem is that if time is not tracked during the suspend, the suspension has not or can be treated as not having happened. The answer then would be 3 minutes. If time is tracked during the suspension, the select should timeout 1 minute after resume. Another possible solution would be: it depends on what CLOCK_MONOTONIC does. It's probably good to have CLOCK_MONOTONIC represent a difference of 3 minutes when sampled across the timed-out select(2). Anyway: I have not invested anything in understanding timekeeping so I basically don't have any grounds for the statements I make. I think I'd better leave the details to others. I just found the question of what the definition of uptime is interesting in a metaphysical way... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net