From: mentalg@geocities.com
  To  : ggi-develop@eskimo.com
  Date: Tue, 15 Sep 1998 20:02:46 -0400 (EDT)

Re: Time for a stable version release ?

On Wed, 16 Sep 1998, Marcus Sundberg wrote:

> mentalg@geocities.com wrote:
> > 
> > On Tue, 15 Sep 1998, Marcus Sundberg wrote:
> > 
> > > The reason I'm so strongly against the latter case in my example
> > > above is that I don't want to bloat the drawing primitives in
> > > stubs.so and linear-*.so with locks just because some moron out there
> > > can't code properly.
> > 
> > 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.

If locks were put in stubs.c, it ought to be just for the 'external' entry
points -- if a primitive in a stub library needed to call another primitive,
the non-locking (internal) version should be used, as the visual can be
assumed to have been locked. Actually, some sort of ugly macro hack would
also work.

> > > > 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.
> > >
> > > 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.

Yes, you're right there.  I didn't realize what you had been saying until
just now.  And there, indeed, app locking would be appropriate.  But other,
more common, and otherwise sane, combinations of primitives can also stomp
on data structures as well, depending in large part upon the primitive
implementations, which vary greatly according to what combination of target,
stub, helper, and extension libraries are loaded.

> > 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?
> > 
> > Is your main argument is that leaving locking out of the library creates
> > unecessary overhead, as all necessary locking can be done satisfactorally in
> > the application?
> 
> We shouln't leave locking out, but we should only do it when it's
> neccessary. Didn't you read my example?

Maybe you're starting to get through to me.  I'm beginning to have doubts
about the approach I'm suggesting, anyway.

> > (keep in mind, sometimes visuals
> > can interact with one another behind the scenes).
> 
> And when they do we'll use locks, but not otherwise. That's my whole
> point.

I'm still having trouble accepting that we really can make assumptions about
the implementation of primitives, mixing and matching
stub/extension/helper/target libraries (and thus primitive implementations)  
as we do.

And actually, even a function that just stuffs bytes into a framebuffer
accesses the visual structure to find out the address, stride, etc. of the
framebuffer.  Locking is needed even in that case, isn't it?

> > Unless the application
> > just wants to stick a single mutex on the whole library, and go through
> > that, application-implemented locking has to make a lot of assumptions about
> > the internal organization and internal side-effects of the library, and I
> > would contend that such assumptions are not safe in an application.
> 
> It doesn't have to make any assumptions at all. When it's obvious
> that an operation will change internal data (ie ggiSetMode()) the
> app will lock, and when it's not obvious we'll use locks.

So ... we split the task of locking the internal library data structures
between the app and the library?  I still feel weird about it.  Although
when it comes to things like drawing before modesetting, it is certainly the
application's responsibility to prevent that.

-=MenTaLguY=-