From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Sat, 12 Sep 1998 23:45:07 +0200 (MEST)

Re: Time for a stable version release ?

> > 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.
> 
> This sound like a good idea. But why just not pass the buffer
> number. 

Because I want to keep it generic. I'd like to be able to use the very
same ggiLock function to lock down anything that might one day need to be
locked down.

> Every buffer has a number which you pass to ggiDBGetBuffer(),
> and if we pass that to the locking functions we can just hide all the 
> dirty lock structures in the target. The user shouldn't need to change
> those structures anyway, right?

Yes. And I am advocating to hide those structs just like we do with
the visual. LibGGI knows how they look and work, but for the
application it is just a typedef for a void *.

> Well, if you say so... ;-)
> Personally I don't really like all these functions that returns
> a state that the application is in charge of setting anyway. If the app
> doesn't know when it has something locked or not I consider it broken.

The App might have spawned a thread and the thread might have locked the
buffer or vice versa.

We have a fullscreen web browser and a thread animate_logo.
The thread might want to check, if the app has locked the buffer, and
only if it hasn't it would do so itself and update the logo.

TryLock might be a better name.

I.e. a version of Lock that fails, if the lock cannot be acquired.

CU,Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =