Issues with struct timespec

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues with struct timespec

Mark Pizzolato - pthreads - win32
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 | Threaded
Open this post in threaded view
|

Re: Issues with struct timespec

Ross Johnson-2
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
>