From: mentalg@geocities.com
  To  : andreas.beck@ggi-project.org
  Date: Sat, 12 Sep 1998 15:21:25 -0400 (EDT)

Re: Time for a stable version release ?

On Sat, 12 Sep 1998 becka@rz.uni-duesseldorf.de wrote:

> > * To lock or not to lock... ggiLock/ggiUnlock would greatly increase
> >   the performance of libggi 
> 
> Yes - not now, but it might later ... However we should specify it a 
> little more closely. I'd vote for this call taking a pointer to a struct
> that is in the descriptor of the thing you want to lock.
> 
> A single global lock is IMHO not good.

I didn't think that's what they were suggesting ... just a per-visual
lock...

> I am thinking of something like
> 
>    ggiDrawSomeThing(...);
>    ggiLock(db->lock);
>    access this directbuffer
>    ggiUnlock(db->lock);

Yeah, making it per-directbuffer rather than per-visual is a better idea
anyway.

> If the struct contains pointers to lock/unlock functions, the target can
> customize the behaviour according to its needs. KGI can use the complicated
> shared user-/kernelmem scheme I proposed at some time, while others can
> just use simple locks eventually coupled with a ggiFlush() or something.
> 
> Ah yes - and things like CheckLock might be useful, too - right ?

I'd suggest ggiDBTryLock().

-=MenTaLguY=-