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
Subject:	RE: [PATCH] gettimeofday time travels
MIME-Version:	1.0
Date:	Mon, 13 May 2002 20:39:49 +1000
X-MimeOLE:	Produced By Microsoft Exchange V6.0.5762.3
content-class:	urn:content-classes:message
Message-ID:	<FC169E059D1A0442A04C40F86D9BA7600C6081@itdomain003.itdomain.net.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	"Philip Aston" <paston AT bea DOT com>, <cygwin AT cygwin DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id g4DAgXD28463

> -----Original Message-----
> From: Philip Aston [mailto:paston AT bea DOT com] 
> Sent: Monday, May 13, 2002 6:57 PM
> To: cygwin AT cygwin DOT com
> Subject: Re: [PATCH] gettimeofday time travels
> 
> 
> 
> 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?

None here, but I don't know this bit of code well. Hopefully someone
else will comment.
 
> 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.

Incremental is best. Lower risk. Structure what you put in so that it
should be easily refactored, but that's all.
 
> 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.

Mutex's are the usual solution. Also there's a thread safe list in
thread.h. (It uses InterLocked calls).
 
> 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?

Not by me. There are other ways to deal though. (for example just link
to head in each object. Or, have inserts and deletes managed by the
client not the object itself.)

Rob

--
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/

- Raw text -