Index: [thread] [date] [subject] [author]
  From: mentalg@geocities.com
  To  : ggi-develop@eskimo.com
  Date: Tue, 15 Sep 1998 17:31:05 -0400 (EDT)

Re: Time for a stable version release ?

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

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

My (counter-)argument is that locking support of some sort in the library is
really necessary, because the library knows better how to lock its internal
data structures than the application does (keep in mind, sometimes visuals
can interact with one another behind the scenes).  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.

How do the rest of you folks feel about this?

-=MenTaLguY=-

Index: [thread] [date] [subject] [author]