From: mentalg@geocities.com
  To  : ggi-develop@eskimo.com
  Date: Mon, 14 Sep 1998 18:25:31 -0400 (EDT)

Re: Time for a stable version release ?

On Mon, 14 Sep 1998, Marcus Sundberg wrote:

> becka@rz.uni-duesseldorf.de wrote:
> > So the question is :
> > 
> > Should we just make some call that allows/disallows access to framebuffers
> > or make a whole locking system, making LibGGI fully threadsafe and also
> > doing away with that silly SYNC-mode problem ?
> 
> We should have a locking system that makes it possible to use libggi
> in a threadsafe way without too much trouble, but we should IMNSHO not
> implement a _complete_ locking scheme.

A complete locking scheme isn't that complex.  Any less complete, and it
won't work reliably.  Poor locking isn't something you can easily make up
for at higher levels without hurting performance.

> Example:
> Making sure that the the user can use ggiPutPixel() in two threads,
> ggiDrawLine() in one thread and ggiSetPalette() in one thread
> simultaneously is our problem.
> Handling the case where one thread calls ggiSetMode() and another
> calls ggiPutBox() at the same time is NOT our problem, as the user
> can easily implement this himself.

Still problems with potentially trashing the ggi_visual structure or private
data there.  Implementing a locking scheme such as you describe would
actually prove more complex (and less reliable) than a relatively
straighforward "correct" locking implementation.

-=MenTaLguY=-