Re: [Plib-devel] glIsValidContext

[Steve B. <sjb...@ai...>]

Bram Stolk wrote:

> I would record the creation of a context in plib, and do your
> context check as follows:

PLIB doesn't create the rendering context, we leave that up to
the windowing library (SDL, freeglut, FLTK, etc).

       (Well...unless you use PLIB's PW library...in that case,
       we *DO* create the rendering context - but SSG, FNT and
       PUI (who make the glIsValidContext calls) are all independent
       from PW - so we won't make that connection).

Since it's the application's responsibility to create a rendering
context, we merely check that he did it right as a defensive mechanism.

However, it's been a LONG time since I've seen a complaint about the
check under Linux - and I've never had complaints from Windows, IRIX
or Mac users.  I thought that all 'recent' OpenGL implementations
had the problem licked.  IIRC, the last time it showed up was a couple
of years ago with a RedHat release that used a 'hacked' version of Mesa
instead of the officially sanctioned release from the Mesa team.

That's why I'm suspicious that this is coming from the FreeBSD
community.  They may either have a newly broken OpenGL implementation
or (*FAR* more likely IMHO) a thread mechanism that exposes an existing
race condition in some particular application they are testing with.

That makes sense because they have suspicions that threads are somehow
implicated here - and a program that used threading extensively would
be quite capable to doing something dumb like opening the GL context
in the 'main' program *AFTER* launching a parallel thread that would
render to that context.   A bug like that would evade PLIB's check - and
(depending on the precise thread scheduling) might work perfectly under
Windows and Linux.  However, FreeBSD has a different threading mechanism
with utterly different scheduling - so a broken program that SEEMED to
work OK under Linux and Windows could EASILY be broken by a different
scheduler.

If that hypothesis is correct then removing PLIB's check would be a very
bad thing indeed.  It would allow the application to run without crashing,
but OpenGL calls made before the rendering context was opened would be
ignored by 'correctly functioning' OpenGL implementations.  You might
see odd flakey rendering problems - but maybe the application would
appear to work OK.

Anyhow...

To make this *utterly* clear:

1) PLIB is doing *exactly* the right thing right now.

2) All we are discussing is a kludge to work around someone elses problem.

3) In order to fix this problem, SOMEONE has to make a change.  It's either
    the OpenGL/Windowing library/driver, the threading library, the application
    or us.

    However we *KNOW* the problem isn't ours - we are only the good guys
    who are detecting the problem.

    Why then would you change the one part of the system that's letting
    you find the bug?   If we kludge PLIB then the underlying problem
    will probably never be found.

    The only reason this is even being thought about is that we are a
    relatively small, responsive team and someone can see a one-line
    kludge to get something half-assedly working.

So, I think we should leave the check in place and punt the problem to
whoever broke the system!

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----