[ANNOUNCE] libxshmfence 1.0

[Matthieu Herrb]

On Sat, Nov 02, 2013 at 12:39:40AM -0700, Keith Packard wrote:
> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
> 
> > What about platforms which don't have <linux/futex.h> ?
> 
> I looked into alternate synchronization mechanisms; I couldn't figure
> out how to use standard pthread APIs to provide the desired semantics.
> 
> Here's the detailed write up I did that describes the SyncFence
> semantics and how those map directly to Linux Futexes:
> 
>         http://keithp.com/blogs/Shared_Memory_Fences/

Ah, if the whole point of not beeing able to use pthreads is about
mixing 32 and 64 bits mode clients on the same X sever, OpenBSD is not
really affected since they choosed to not support 32 bits processes on
their 64 bits kernels. So I can move forward and implement xshmfence
for OpenBSD using your code below :)

(Well OpenBSD has some Linux compat code too, where pthread objects
will probably not be shareable between linux and native processes, and
this could be a problem, but I doubt that the linux compat code
actually allows to run a dri client anyways).

> 
> If you can figure out how to build this with pthread mutexes and/or
> semaphores, then we could create a version of xshmfence that worked
> using regular pthread functions. As I understand it, pthread
> synchronization primitives are supposed to work across processes that
> share memory, even if they use different virtual addresses to reference
> the same object.
> 
> Off the top of my head (sorry for the int32_t * argument type):
> 
> struct xshmfence {
>         pthread_mutex_t lock;
>         pthread_cond_t  wakeup;
>         int             value;
>         int             waiting;
> };
> 
> /**
>  * xshmfence_trigger:
>  * @f: An X fence
>  *
>  * Set @f to triggered, waking all waiters.
>  *
>  * Return value: 0 on success and -1 on error (in which case, errno
>  * will be set as appropriate).
>  **/
> int
> xshmfence_trigger(int32_t *v) {
>         struct xshmfence *f = (struct xshmfence *) v;
> 
>         pthread_mutex_lock(&f->lock);
>         if (f->value == 0) {
>                 f->value = 1;
>                 if (f->waiting) {
>                         f->waiting = 0;
>                         pthread_cond_broadcast(&f->wakeup);
>                 }
>         }
>         pthread_mutex_unlock(&f->lock);
>         return 0;
> }
> 
> /**
>  * xshmfence_await:
>  * @f: An X fence
>  *
>  * Wait for @f to be triggered. If @f is already triggered, this
>  * function returns immediately.
>  *
>  * Return value: 0 on success and -1 on error (in which case, errno
>  * will be set as appropriate).
>  **/
> int
> xshmfence_await(int32_t *v) {
>         struct xshmfence *f = (struct xshmfence *) v;
> 
>         pthread_mutex_lock(&f->lock);
>         if (f->value == 0) {
>                 f->waiting = 1;
>                 pthread_cond_wait(&f->wakeup, &f->lock);
>         }
>         pthread_mutex_unlock(&f->lock);
>         return 0;
> }
> 
> /**
>  * xshmfence_query:
>  * @f: An X fence
>  *
>  * Return value: 1 if @f is triggered, else returns 0.
>  **/
> int
> xshmfence_query(int32_t *v) {
>         struct xshmfence *f = (struct xshmfence *) v;
>         int value;
> 
>         pthread_mutex_lock(&v->lock);
>         value = f->value;
>         pthread_mutex_unlock(&v->lock);
>         return value;
> }
> 
> /**
>  * xshmfence_reset:
>  * @f: An X fence
>  *
>  * Reset @f to untriggered. If @f is already untriggered,
>  * this function has no effect.
>  **/
> void
> xshmfence_reset(int32_t *f) {
>         struct xshmfence *f = (struct xshmfence *) v;
> 
>         pthread_mutex_lock(&f->lock);
>         f->value = 0;
>         pthread_mutex_unlock(&f->lock);
> }
> 
> > Right now, xorg-server cannot build without xshmfence, and xshmfence cannot
> > build without Linux-only API's.   There needs to be some way for Solaris,
> > BSD, MacOS and Cygwin to build without this, whether it's making xshmfence
> > optional for xorg-server or making xshmfence work with mutexes or other
> > portable API's.
> 
> We can certainly disable DRI3 for platforms that don't have xshmfence
> available. I'm sorry I didn't do that when I added the DRI3 tests to the
> configure script.
> 
> -- 
> keith.packard at intel.com



> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel


-- 
Matthieu Herrb