public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Mark Pizzolato - pthreads - win32	<MarkPizzolato-pthreads-win32@subscriptions.pizzolato.net>
To: "pthreads-win32@sourceware.org" <pthreads-win32@sourceware.org>
Subject: Issues with struct timespec
Date: Thu, 12 Jan 2012 21:06:00 -0000	[thread overview]
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F7EF53176A6@REDROOF2.alohasunset.com> (raw)

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

             reply	other threads:[~2012-01-12 21:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-12 21:06 Mark Pizzolato - pthreads - win32 [this message]
2012-01-13  2:09 ` Ross Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0CC6789C1C831B4C8CCFF49D45D7010F7EF53176A6@REDROOF2.alohasunset.com \
    --to=markpizzolato-pthreads-win32@subscriptions.pizzolato.net \
    --cc=pthreads-win32@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).