From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 415 invoked by alias); 13 Jan 2012 02:09:20 -0000 Received: (qmail 32448 invoked by uid 22791); 13 Jan 2012 02:09:17 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from bender.grapevine.net.au (HELO bender.grapevine.net.au) (203.129.32.139) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Jan 2012 02:09:03 +0000 Received: from localhost (localhost [127.0.0.1]) by bender.grapevine.net.au (Postfix) with ESMTP id 49EF4210031; Fri, 13 Jan 2012 13:09:01 +1100 (EST) Received: from bender.grapevine.net.au ([127.0.0.1]) by localhost (bender.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YksPjgWRt1ER; Fri, 13 Jan 2012 13:09:01 +1100 (EST) Received: from [192.168.2.2] (ppp-124.44.129.203.grapevine.net.au [203.129.44.124]) (Authenticated sender: Ross.Johnson@homemail.com.au) by bender.grapevine.net.au (Postfix) with ESMTPA id EEFD921001F; Fri, 13 Jan 2012 13:09:00 +1100 (EST) Message-ID: <4F0F91F7.6050300@homemail.com.au> Date: Fri, 13 Jan 2012 02:09:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mark Pizzolato - pthreads - win32 CC: "pthreads-win32@sourceware.org" Subject: Re: Issues with struct timespec References: <0CC6789C1C831B4C8CCFF49D45D7010F7EF53176A6@REDROOF2.alohasunset.com> In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F7EF53176A6@REDROOF2.alohasunset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2012/txt/msg00004.txt.bz2 I've pondered the wisdom of providing the pre-built dlls for many years. I see them as a way for new users to get started quickly or for evaluation etc, but for more ambitious projects or applications I would encourage building the library from source in the same environment as the project. On 13/01/2012 8:06 AM, Mark Pizzolato - pthreads - win32 wrote: > Hi there, > > In the older versions of pthreads-win32 struct timespec had a tv_sec member which was of type long. > > In the current CVS code base this member has been changed to be of type time_t. > > The only reason struct timespec exists in pthreads-win32 is to support pthread_cond_timedwait(). Pthread.h is providing a definition for struct timespec since, in general there is no other use of that structure in a win32 programming environment. It is unique to pthreads. > > A problem exists for an application which may use the provided struct timespec definition with pthread_cond_timedwait(). If that application is linking against a prebuilt version of the pthreads code (the most common case), the pthreads library will have been built with a time_t type which is whatever the current compiler/build default size for that type (64bits these days, but 32bits in the past). Meanwhile, the application using pthreads can have a time_t type which could be 32 or 64 bits completely depending on compile time defines. Calls to pthread_cond_timedwait() will be passing a struct timespec which may or may not have a time_t element size consistent with the time_t in use when the pthread library was built. > > I would suggest that struct timespec should use a non variable sized type for the tv_sec member. A type of long should be just fine for normal uses of pthread_cond_timedwait() for most of the next 36 years. A 64bit type could just as well be used if all of the pthread-win32 target platforms support 64bit numbers, or it could be a fixed size but be specific to the platform as needed. > > While we're here, anyone who uses a struct timespec passed to pthread_cond_timedwait() actually needs to construct the contents of that structure in some way. We may want to provide a clock_gettime() implementation as part of pthreads-win32 to make the use of this API a little more natural and/or portable. > > I'll be glad to suggest specific code for these ideas depending on what others think of the issue. > > Looking forward to a discussion. > > - Mark Pizzolato >