From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Wed, 16 Sep 1998 03:01:15 +0000

Re: Time for a stable version release ?

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.

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

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

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

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se