HOpenGL and --enable-threaded-rts

Andrew J Bromage andrew@bromage.org
Thu, 20 Jun 2002 10:21:26 +1000

G'day all.

On Wed, Jun 19, 2002 at 10:29:52AM +0200, Wolfgang Thaller wrote:

> The problem here is with OpenGL, not with GLUT. OpenGL requires some 
> thread-local state to be set correctly in order to operate. Surely you 
> wouldn't suggest reimplementing OpenGL (plus all OpenGL video drivers 
> for every platform/OS/graphics card combination out there) in Haskell?

Point taken.

Actually, many high-level language GUI interface bindings spawn a
dedicated thread to handle all the graphical I/O and everything else
is done with inter-thread communication.  It would be fiddly and
unnecessarily painful, but you could probably do that with no changes
to the rts so long as the dedicated thread wasn't a Haskell thread.

> I agree that it is difficult, and it can cause headaches. But in order 
> to write "real-world" applications in Haskell, there is no way around 
> it. In order to write GUI applications, I need a binding to Win32 (a 
> "C-specific" framework) for Windows, [...]

This may be a definitional issue, but I wouldn't call Win32 a
framework.  MFC is a framework.  POSIX isn't.  BeOS is somewhere
on the boundary.

> Most of those use callbacks of some sort.

Most of them don't require thread local state for correct operation.

> Exceptions just require a little more marshaling, I think. As for the 
> even hairier things, I don't think "they" are going to add many more 
> crazy things to the C language family, so C-specific frameworks 
> shouldn't hold too many surprises in store for us...

I'm constantly surprised by the hairiness you can find even in
constructing C++ bindings for C APIs.  It's not going to be long,
for example, before you find an API which requires a callback to use
varargs, at which point we'll be having this conversation yet again.

Andrew Bromage