[cairo] Review of: [cairo-mutex] Add default implementation for CAIRO_MUTEX_INIT that uses CAIRO_MUTEX_NIL_INITIALIZER. This used to be the implementation for pthread because pthread_mutex_init() is broken. See d48bb4fbe876a93199ba48fcf5f32734fbe18ba9.

[Paul Davis]

On Mon, 2007-04-23 at 16:55 -0400, Behdad Esfahbod wrote:

> I don't agree.  First, do we even envision a new platform added in the
> following two years?  If not, this discussion is irrelevant.  And adding
> a new platform is dead easy now: you just look at the other ones, and
> copy and adapt one of them.  Of the four we have now, three look VERY
> similar.  The only exception is pthread because it doesn't need static
> initialization.
> 
> In fact it became so easy that I went on and implemented BeOS (a
> platform I've never seen).  It was six lines only:
> 
>   typedef BLocker* cairo_mutex_t;
> 
> # define CAIRO_MUTEX_LOCK(name) (name)->Lock()
> # define CAIRO_MUTEX_UNLOCK(name) (name)->Unlock()
> # define CAIRO_MUTEX_INIT(mutex) (*(mutex)) = new BLocker()
> # define CAIRO_MUTEX_FINI(mutex) delete (*(mutex))
> # define CAIRO_MUTEX_NIL_INITIALIZER NULL

congratulations, you are well on your way towards virtualizing the
already virtual. what is the justification for cairo-specific thread
code? why are you not just using an existing cross platform library,
even if that means ripping out its thread support? pthreads is already
virtualized, and then glib sits on top of that, and wine has its own
virtual handlers for things that might be pthreads and might not be.
P.1003 *is* a standard folks. Yes, MS don't provide a version, but is
this the sole justification for reimplementing (badly, or at least,
superficially) was has already been done?