From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21855 invoked by alias); 18 May 2002 06:18:03 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 21832 invoked from network); 18 May 2002 06:18:02 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 18 May 2002 06:18:02 -0000 Received: from redhat.com (vpn50-7.rdu.redhat.com [172.16.50.7]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g4I6I1u32524 for ; Sat, 18 May 2002 02:18:01 -0400 Received: by redhat.com (Postfix, from userid 201) id 105A41B854; Sat, 18 May 2002 02:18:02 -0400 (EDT) Date: Sat, 18 May 2002 10:35:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: [PATCH] gettimeofday time travels V2 Message-ID: <20020518061802.GA10347@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <15654.52373.497253.37486@bea.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15654.52373.497253.37486@bea.com> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2002-05/txt/msg01193.txt.bz2 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. >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. 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... The w32api part should be posted separately to cygwin-patches so that Danny will see it and apply it. 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/