HOpenGL and --enable-threaded-rts
Andrew J Bromage
Thu, 20 Jun 2002 10:21:26 +1000
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?
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.