From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32637 invoked by alias); 12 Jan 2012 21:06:57 -0000 Received: (qmail 32619 invoked by uid 22791); 12 Jan 2012 21:06:55 -0000 X-SWARE-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID X-Spam-Check-By: sourceware.org Received: from mail.alohasunset.com (HELO mail.alohasunset.com) (173.164.129.123) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Jan 2012 21:06:34 +0000 Received: from ASSP-nospam ([127.0.0.1]) by alohasunset.com with MailEnable ESMTP; Thu, 12 Jan 2012 13:06:24 -0800 Received: from 127.0.0.1 ([127.0.0.1] helo=REDROOF2.alohasunset.com) by ASSP-nospam id rclV=7X=subscriptions.pizzolato.net=markpizzolato-pthreads-win32; Thu, 12 Jan 2012 13:06:24 -0800 Received: from REDROOF2.alohasunset.com ([fe80::aba9:1f8e:eb79:f41]) by REDROOF2.alohasunset.com ([fe80::aba9:1f8e:eb79:f41%10]) with mapi; Thu, 12 Jan 2012 13:06:24 -0800 From: Mark Pizzolato - pthreads - win32 To: "pthreads-win32@sourceware.org" Date: Thu, 12 Jan 2012 21:06:00 -0000 Subject: Issues with struct timespec Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F7EF53176A6@REDROOF2.alohasunset.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00003.txt.bz2 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 tim= e_t.=20=20 The only reason struct timespec exists in pthreads-win32 is to support pthr= ead_cond_timedwait(). Pthread.h is providing a definition for struct times= pec since, in general there is no other use of that structure in a win32 pr= ogramming environment. It is unique to pthreads. A problem exists for an application which may use the provided struct times= pec definition with pthread_cond_timedwait(). If that application is linki= ng 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 whate= ver the current compiler/build default size for that type (64bits these day= s, 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 com= pile time defines. Calls to pthread_cond_timedwait() will be passing a str= uct timespec which may or may not have a time_t element size consistent wit= h the time_t in use when the pthread library was built.=20=20 I would suggest that struct timespec should use a non variable sized type f= or the tv_sec member. A type of long should be just fine for normal uses o= f pthread_cond_timedwait() for most of the next 36 years. A 64bit type cou= ld just as well be used if all of the pthread-win32 target platforms suppor= t 64bit numbers, or it could be a fixed size but be specific to the platfor= m 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 s= ome way. We may want to provide a clock_gettime() implementation as part o= f pthreads-win32 to make the use of this API a little more natural and/or p= ortable. I'll be glad to suggest specific code for these ideas depending on what oth= ers think of the issue. Looking forward to a discussion. - Mark Pizzolato