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

Re: Time for a stable version release ?

On Sun, 13 Sep 1998 becka@rz.uni-duesseldorf.de wrote:

> My idea is, that LibGGI internally should have a ggiDrawfunction-Lock
> which gets set/reset be running drawing functions, while they are doing
> critical things, where no others may interfere. 
> 
> And example would be a net-target assembling a packet in some buffer that
> would also be used by another thread.
> 
> As the locking functions are set within that locking structure, we can 
> make up any needed behaviour for the locking like
> 
> - a DrawLock also locks all DBs, while DBs can be locked individually
> - the DrawLock can be implemented with a kernelside "delayed UnLock", when
>   the Accel is ready again
> - ...

So, locking a db would imply locking the visual until the db lock was
aquired (after which I suppose the visual lock would be released)...

> So o.k. let's propose something, so we can talk about it:
> 
> struct ggi_lock {
> 
> 	struct lockfunctions {
> 		int (*lock)(ggi_visual_t vis,struct ggi_lock *lock);
> 		int (*unlock)(ggi_visual_t vis,struct ggi_lock *lock);
> 		int (*trylock)(ggi_visual_t vis,struct ggi_lock *lock);
> 	}
> 	int locktype;	/* In case someone wants to build a generic handler */
> 	union lockdatastructs {
> 		pthread_mutex_t mutex;
> 		spinlock	slock;
> 		kernel_shared_lock	kslock;
> 		int		naive_lock;
> 		void 		*whatever;
> 		struct ggi_lock *for_"shared"_locks;
> 	}
> }
> 
> Would that be feasible ?

Wow.  Is all that complexity really necessary?  (yes, I imagine it'd be
feasible -- I guess speed wouldn't be too bad if ggiLock() and friends were
macros)

> I think there should be one lock in the visual for drawing operations,
> and one per directbuffer.
> 
> Moreover we should provide some sets of "standard" locking functions
> for the two common cases of a simple lock or a "redirected lock" that
> would be used for coupling two locks.
> 
> O.K. - comments ?

Yeah, the coupled locks construct is _very_ important.  I don't quite see
how the rest is necessary, though ... maybe just the pthreads and coupled
lock types?  Dunno.  I'll have to think about this; in my experience you
generally haven't come up with something that complex without very good
reasons. :)

-=MenTaLguY=-