In your message of 20 January 2000 you write:
> On Thu, Jan 20, 2000 at 04:42:55PM -0800, David Blythe wrote:
> > | I'm a little bit opposed to this, as it makes it quite impossible to
> > | get decent performance with a static dispatch table (which our
> > | implementation uses). Wouldn't it be possible to have something
> > | similar to what SUN is using, where you explicitely register that you
> > | want to use thread-safeness. This avoids pretty much every kind of
> > | overhead.
> >
> > I suggest not following this path. this just makes things that
> > much more complicated for apps and layer libraries if they
> > have to keep second guessing each other. the glx specification
> > specifies how threading works -- other companies have had successful
> > implementations for 5+ years, and I see no reason to break
> > compatibility by introducing even more convoluted threading api.
>
> Also, the app is being fairly explicit IMO - if it does a
> MakeCurrent when another context is already current to another thread,
> then it's saying "I'm going multithreaded".
Hmmm ... Party of my concern here is that there are different
implementations of pthreads in different versions of libc (glibc). We
have found that there are a lot of portability problems between
glibc 2.0 and glibc 2.1 (yes and between 2.1 and 2.1.2 it's even
worse). Adding the requirement to be thread-safe by default adds yet
another big unknown in binary compatibility. My prefference would be
either to have two libraries (one threadsafe, the other not), or some
mechanism, where a library could figure out whether thread-safeness is
required or not.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
