native threads vs. -threaded
donn at avvanta.com
Sat Mar 13 17:54:45 EST 2010
Quoth Simon Marlow <marlowsd at gmail.com>,
>> 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?
By main thread I mean the original thread spawned by the process
creation; the thread spawned by the foreign library window code
is a non-main thread. I wish I knew why it dies! Without -threaded,
I do get tracebacks from the various and sundry stack corruptions
and whatever eventually occurs, but with -threaded, death is quick
and silent. And, as far as I can tell, it happens in the foreign
library code, not while executing a callback. The same type of
callback works fine in the main thread (this API uses the same dispatch
loop for the application itself, but it just doesn't spawn a new
thread in that case.)
> 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?
Yes, each window runs its own thread. If it helps to have names,
the BWindow::Show function spawns the thread, and from there its
event loop calls virtual functions in the BWindow and BView classes
that the application may override. That's where control goes back
to the Haskell application, via foreign "wrapper" functions.
But of course all that is perhaps unnecessary elaboration. The key
points are, threads of foreign origin, with callbacks to Haskell
foreign "wrapper" functions. Does the wrapper rts_lock() account
for everything, or do threads need some initial setup I need to
Donn Cave, donn at avvanta.com
More information about the Glasgow-haskell-users