From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Wed, 16 Sep 1998 09:38:39 +0200 (MET DST)

Re: Time for a stable version release ?

Hi !

> > There shouldn't normally have to be locks in there (at least, not for the
> > sake of LibGGI -- the implementation may require other locking).  All you
> > need is to have locks in the library entry points -- in the main
> > lib/libg*/stubs.c
> That's just as bad. If we for any reason really need to put locks in the
> ggi*Pixel() fundtions for thread safety, then we have to make that a 
> compiletime option.

Well - I'll just go ahead making more friends by disagreeing with both of you 
:-). 

I say that locking should be handled by the target/backend code. This will mean
_no_ locks in "normal" targets that always draw on some memory area or
something like that.

However it will mean locks around say X communication. Things that are locked
via the atomicity of a kernel call like ioctl also need no locks.

So basically there need not be many locks around to hinder performance.

> > > You are SUPPOSED to get thrashed internal data if you try to draw
> > > at the same time as changing the mode. If people can't code properly
> > > using threads they either stay off threads, or they lose.
> > Okay, this is really a philosophy thing -- should the library bother with
> > thread safty at all, or should it be left to the application programmer?

Well - if you need locks to protect you from yourself for _that_ case, you
are nuts anyway. You will most likely draw garbage anyway depending on what
(new or old mode) is assumed by the draw function.

> We shouln't leave locking out, but we should only do it when it's
> neccessary. 

Oh - seems I didn't actually disagree with Marcus ... :-)

CU,ANdy

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