From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Tue, 15 Sep 1998 15:20:44 -0700 (MST)

Re: Time for a stable version release ?

On Mon, 14 Sep 1998, Marcus Sundberg wrote:

> mentalg@geocities.com wrote:
> > 
> > On Sun, 13 Sep 1998, Marcus Sundberg wrote:
> > > Why should we bloat libggi with this??
> > > Libggi is not a high-level gfx API. We should make sure that
> > > calling drawingprimitives, setpalette and such functions from
> > > different threds work, but that's it.
> > > Things like the above, synchronising modesetting between threads
> > > etc. belongs either in the app or in a higher level API.
> > 
> > The locks Andy describes are an integral part of thread safety, as well as
> > being useful for what he describes.  In the case of indirect framebuffers
> > (i.e. X), it also provides the library with an idea when it should flush
> > that to the display when the directbuffer is unlocked.
> 
> Yes, I know that. But the question I'm asking is if there's any
> need to lock a _framebuffer_ for threadsafety. I perfectly understand
> the need for locks in drawing primitives which may be accessing
> accel registers and other things that may be fscked up by writing
> to them in the wrong order.
> 
> But for the framebuffer we don't need any _locks_, we just need a
> function (ggiEnableDB()) that will block until the accel queue is
> flushed. Making sure that the user doesn't use the drawingprimitives
> between ggiEnableDB() and ggiDisableDB() is NOT our problem.
> 
> As I said the only possible problem with multiple processes/threads
> accessing a framebuffer would be on a SMP machine, and I'm really
> in doubt if this can cause trouble on any hardware.

As I said in an earlier message this matters when the framebuffer is
emulated (ie you're -not- talking directly to the hardware).  IE: X,
network connections, memory visuals...

Though the worst I'd suspect you'd see from those is incomplete updates.
(the occasional messed-up pixel)

AFAIK some broken hardware fubars if it jumps around in memory too much or
if multiple addresses are openned in multiple CPU's but I would -hope-
that none of this hardware exists anymore.  [it used to.  Multi-CPU 486's
and below as well as a few other broken architectures.  PCI doesn't have
this problem and any multi-processor system worth it's salt handles bus
arbitration in such a way as to not lockup under this circumstance]

G'day, eh? :)
	- Teunis