Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 13 May 2002 12:53:33 -0400
From: Christopher Faylor <cgf-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [PATCH] gettimeofday time travels
Message-ID: <20020513165333.GA2338@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <15547 DOT 16136 DOT 163472 DOT 840007 AT bea DOT com> <15579 DOT 35225 DOT 764199 DOT 450263 AT bea DOT com> <15591 DOT 64698 DOT 290124 DOT 380527 AT bea DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15591.64698.290124.380527@bea.com>
User-Agent: Mutt/1.3.23.1i

On Mon, May 13, 2002 at 09:56:58AM +0100, Philip Aston wrote:
>
>Philip Aston writes:
> > Christopher Faylor writes:
> >  > The correct solution is to resync after events which cause the
> >  > clock to stop.
> > 
> > OK, I'll have a crack at this over the weekend following David's
> > hints.
>
>Short of some unexpected wParam values, which I'll track down, I now
>have this working.
>
>I have some design questions. Please help me ensure my patch is up to
>scratch..
>
>1. Currently I'm leveraging the event loop for the hidden window that
>is created for alarm and ualarm support (window.cc). This involves a
>call to gethwnd() create that window if it doesn't exist. I presume
>this is fine as the socket support does the same. Any objections?

If there is any way to avoid starting up the windows event-loop thread,
it should be investigated.  Normal cygwin apps do not start this thread
and so it should be avoided if possible.

>2. Should I implement a generic mechanism for listening to power
>events? Currently I've just added a static hires::reprime() method
>which is called on the appropriate power event.

General is always good.

>3. The reprime() method iterates over a linked list of hires objects.
>The hires ctor inserts a hires into this list. Do I need to worry
>about thread safety here? If so, what's a typical solution? I didn't
>see any handy thread safe list.

It may make sense to just make all of the members of the hires class
static since they are just maintaining global state.

>4. Similarly for the dtor - I'm planning to assert here, rather than
>faff with a double linked list. This means that hires's can never be
>deleted. OK?

There is no reason to delete hires as cygwin uses them.  However, to
answer your general question, a 'muto' is what is normally used
internally for locking.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/