native threads vs. -threaded

Donn Cave donn at
Fri Mar 12 11:38:38 EST 2010

I have been working on a Haskell interface to the platform API
for Haiku (was BeOS.)  It's C++, but the interesting thing at
the moment is the use of threads - a UI window gets its own
thread, and whatever Haskell code will be executed by callbacks
from that thread.

So it was surprising when this turned out to be incompatible
with the -threaded link option.  With that option, I get one
callback from a non-main thread, and then that native thread
will die, shortly after return from the callback.

Results without -threaded are not really so good either (the
application may run and work for a while, but inevitably fail
with various errors that I suppose might be expected),  so ...
what do my threads need, to make -threaded work?

The callbacks are `foreign "wrapper"' functions, which means
rts_lock() is already getting called.  It looks to me like
that should work the same as if my thread had been invoked
via forkOS, true?  Is there anything else that I missed, that
needs to be done to set the thread up for GHC?

(I had been thinking this would not be a unique situation,
rather there would be several other GUI toolkits out there
that use threads in this obvious way, but after a brief review
of the ones I usually hear about, not so sure.  If there's
another library that uses OS threads this way, with Haskell
bindings already, that might be something I could steal a
clue from.)


	Donn Cave, donn at

More information about the Glasgow-haskell-users mailing list