[HOpenGL] HOpenGL and --enable-threaded-rts

[Andrew J Bromage]

G'day all.

On Tue, Jun 18, 2002 at 05:58:15PM +0100, Alastair Reid wrote:

> A further piece of what one might call thread local state is
> 'recursive locks' like those found in Java.

Recursive locks arguably should be part of the lock abstraction, not
"thread local state ".  Since all it costs is another counter, it's
almost trivial for the lock implementation (usually the OS) to
implement it, of only as an option.

For comparison: all Win32 built-in locks (Win32 confusingly
differentiates "mutexes" and "critical sections" even though they are
essentially the same thing) are recursive.  Under all pthreads
implementations that I'm aware of, THREAD_MUTEX_RECURSIVE is supported.
I don't know enough about any other platforms to comment, but my bet is
you'll find it pretty much everywhere.

I think you need to look no further than the thread id itself for
"thread local state".  As soon as you want to do anything with the
thread id other than compare equality (even Ord-type comparison is not
supported under pthreads), you have thread local state.

I don't mean to detract from the fine work which the HOpenGL people
have achieved, but I think that binding to the C implementation of GLUT
was, in retrospect, a mistake.  Binding to foreign language-specific
frameworks in general is a mistake, IMO.  Today it's only threads which
you may be able to hack around, but tomorrow, your called-back function
will want to throw an exception, or something even hairier will turn up
and you'll be back where you started.

Sorry for the pessimism, but this is bitter experience talking.

Cheers,
Andrew Bromage