[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lock module improvement

From: Yoann Vandoorselaere
Subject: Re: Lock module improvement
Date: Mon, 21 Jul 2008 13:56:39 +0200

Hi Bruno,

Le lundi 21 juillet 2008 à 12:24 +0200, Bruno Haible a écrit :
> > - Ability to disable specific backend on demand: some implementation use
> > certain functionality that are incompatible with libpth, or depend on
> > library that provide pthread support but no libpth support. As a result,
> > it would be great if it was possible to explicitly disable a given
> > backend.
> I think you can effectively already do it. Like this:
>   gl_LOCK
>   if test $gl_threads_api = pth; then
>     AC_FATAL([The pth threads implementation is not supported by this 
> package.])
>   fi

Thanks! Wouldn't it be better to directly provide support for a given
backend to be disabled (so that configure doesn't export un-supported

> > - Implement support for condition variable.
> You are welcome to contribute a module for this.

I started working on condition variable support. To me, it make sense to
do that directly within the lock module (the code is very much similar
to what currently exist for mutex primitive). Any objection?

> > - Implement support for thread creation.
> Likewise. You find some code for this purpose at the top of tests/test-lock.c,
> which you may be able to reuse.
> > What about function that does not have an equivalent under certain
> > backend (example: no support for condition timeout with libpth).
> Enhancement request to Ralf Engelschall? :-)

That was an error on my side, seems that we can emulate
pthread_cond_timedwait using:

pth_cond_await(cond, mutex, 
 pth_event(PTH_EVENT_TIME, pth_timeout(ts->tv_sec, ts->tv_nsec / 1000));


Yoann Vandoorselaere <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]