native threads vs. -threaded

[Simon Marlow]

On 12/03/10 16:38, Donn Cave wrote:
> 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.

You'll need to elaborate a little.  When you say you "get one callback 
from a non-main thread", are you saying that the external C++ code makes 
a call to a Haskell function?  Was it Haskell that called C++ in the 
first place?  What do you mean by a non-main thread?  Why is the native 
thread dieing?

You said a UI window gets its own thread - who creates that thread?  If 
the app has more than one window, does each window get a different thread?

Cheers,
	Simon

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