Re: [Plib-devel] Patches for FreeBSD

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

Bert Driehuis wrote:

>> That would be very useful.   Do you need developer access to PLIB?
> 
> Yes, please!

You have it - welcome to the team!

>> It's quite possible for a threaded application to open a GL context in
>> one thread and do OpenGL calls in another thread.  It's easy to imagine
>> a situation where there would be a race hazard that would result in some
>> thread implementations allowing the application to work as intended and
>> other thread implementations to show up the problem that was there in 
>> the application all along.
> 
> This is definitely a possibility. It is also possible that NVidia is 
> somehow involved (I'm using the NVidia binary-only libraries).

The nVidia binaries are pretty much the same for BSD and Linux - it's
hard to imagine there would be a difference there - and we have never
had these problems with nVidia under Linux.

> I'll really have to experiment changing one variable at a time, but 
> being able to build Flightgear from CVS would be a very good start :-)

Yes.

> For what it's worth, I think that _if_ there are legitimate uses of not 
> calling glIsValidContext,

...well, I'm not sure 'legitimate' is the right word - but there are reasons
*IF* you are working around a known bug in some other library...

> we should do something like this:
> 
>   if (getenv("PLIB_SKIP_GLCHECK") != NULL) {
>     cout << "Skipping glIsValidContext: use at your own risk!\n";
>   } else {
>     if (!glIsValidContext()) {
>     cout << "ssgInit called without valid OpenGL context\n";
>     cout << "Set PLIB_SKIP_GLCHECK=yes in your environment to skip ";
>     cout << "this test AT YOUR OWN RISK\n";
>     }
>   }

I think the 'else' clause still needs an 'exit()' or an 'assert' or something
to terminate execution.

People are very bad at noticing error messages - especially in interactive
programs that they launch from an icon or menu bar.

Before we had this check in the code, I'd get MANY emails from application
writers and end users complaining that "PLIB is crashing" on such-and-such
architecture - and generally, the quality of their error reports were so
bad that it would take weeks of emailing back and forth to track down what
was going wrong.

With the fatal error check, the application writer sees a clear problem the
very first time he introduces the bug.  The error can't be ignored so he
MUST fix his program.  This has reduced our maintenance traffic considerably.

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