Re: [AD] Mini-synchronization API proposal for 4.1.x

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2002-03-30, Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:
> 
> I think your idea of serializing the events is the way to go, with a single
> system lock to control them. But I'm not sure whether using a dedicated
> thread is the best solution under Windows, so I'll first try to attach the
> event manager to the timer thread.

Hmm, good idea (not just for Windows I mean).

> I guess this solution is not feasible
> with pthreads because pthreads can't block on CVs with a timeout value (a la
> select), is it ?

Howzat? :-)

 - Function: int pthread_cond_timedwait (pthread_cond_t *COND,
          pthread_mutex_t *MUTEX, const struct timespec *ABSTIME)
     `pthread_cond_timedwait' atomically unlocks MUTEX and waits on
     COND, as `pthread_cond_wait' does, but it also bounds the duration
     of the wait. If COND has not been signaled before time ABSTIME,
     the mutex MUTEX is re-acquired and `pthread_cond_timedwait'
     returns the error code `ETIMEDOUT'.  The wait can also be
     interrupted by a signal; in that case `pthread_cond_timedwait'
     returns `EINTR'.

     The ABSTIME parameter specifies an absolute time, with the same
     origin as `time' and `gettimeofday': an ABSTIME of 0 corresponds
     to 00:00:00 GMT, January 1, 1970.

And in case you're wondering:

 - Data Type: struct timespec
     The `struct timespec' structure represents an elapsed time.  It is
     declared in `time.h' and has the following members:

    `long int tv_sec'
          This represents the number of whole seconds of elapsed time.

    `long int tv_nsec'
          This is the rest of the elapsed time (a fraction of a second),
          represented as the number of nanoseconds.  It is always less
          than one billion.

i.e. nanosecond resolution (theoretically :-)