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: Sat, 18 May 2002 14:02:25 +0100
From: "Philip Aston" <paston AT bea DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15598.6233.401150.171276@bea.com>
To: cygwin AT cygwin DOT com
Subject: Re: [PATCH] gettimeofday time travels V2
In-Reply-To: <20020518061802.GA10347@redhat.com>
References: <15654 DOT 52373 DOT 497253 DOT 37486 AT bea DOT com>
	<20020518061802 DOT GA10347 AT redhat DOT com>


Christopher Faylor writes:
 > On Sat, Jul 06, 2002 at 11:55:17AM +0100, Philip Aston wrote:
 > >The list in thread.h is specific to a type, and intrusive. I used a
 > >mutex to create my own thread-safe, non-intrusive list. I used pthread
 > >mutexes instead of mutos since mutos must be allocated statically.
 > 
 > What is wrong with allocating a muto statically?  You only need one for
 > this application in cygwin.

The mutex is part of my generic event listener list. Whilst I allocate
my event listener list statically, others may wish to do otherwise.

 > >Christopher Faylor writes:
 > > > It may make sense to just make all of the members of the hires
 > > > class static since they are just maintaining global state.
 > >
 > >Agree. Personally I'd use a singleton object rather than static
 > >members which would also allow hires to continue to be a wm_listener,
 > >but it amounts to the same thing. However, I didn't do this as I
 > >consider it outside of the scope of the fix.
 > 
 > This looks like nice work but I am still concerned about the necessity
 > of starting up the windows thread and using the windows event loop as I
 > mentioned in previous email.  I'd rather not have that overhead if it
 > can be avoided.

I can't think of anyway to detect the power events other than to run
an event loop.

Note, my implementation will not start the windows thread unless a
hires is used. Unfortunately a hires is used by the strace/printf
methods, so its hard to avoid.

 > For the cygwin part, the patch is also big enough that it requires
 > an assignment. Hopefully you've looked at
 > http://cygwin.com/contrib.html by now...

Yes. I have put the wheels in motion to get a disclaimer from my
employer.

 > The w32api part should be posted separately to cygwin-patches so
 > that Danny will see it and apply it.

Done.


- Phil


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