In general, I think that only the programmer knows what strategy to use.
Do programmers know? I know about my own program, but do I know about the library that I am going to use? Does it use forkOS or forkIO? What will be the consequences if it uses forkIO and I do a lengthy foreign call?
Does the library writer know about my program?
I fear I'll end up wrapping every call to *Haskell* libraries in your "threadSafe" combinator - just to be sure that the library and my program don't interfere.
I'm very afraid of having some long debugging sessions once we have this "feature".
Now, I have an example from the wxHaskell GUI library that exposes some
of the problems with multiple threads. I can't say it can be solved
nicely with forkOS, so I wonder how it would work out with "threadsafe":
In both cases, threadsafe and forkOS, we would have two OS threads, and we would have OS thread context switches between them. So it will get us nowhere to count the OS thread context switches involved (incidentally, handling GUI events is an area where we can easily afford the cost of OS thread context switches).
You would mark the call to the wxWindows event loop as threadsafe (actually, in the CVS version of GHC, "safe" is currently a shorthand for "threadsafe" as nobody has yet provided a logically sound and meaningful definition of the semantics that "safe" should have instead).
In case that wxWindows makes the assumption that it's functions are invoked _from the same OS thread_ that it used to call your callback, you can add "bound" to the foreign export statement for your callback.
Then you would use just forkIO and everything would work.
(If wxWindows doesn't allow access from multiple threads, then of course you can't call wx functions from the thread you just forked. But that's the same no matter which proposal we follow.)
The problem is that the "processor" thread won't run since we have returned
to C-land and the haskell scheduler can't run.
Threadsafe means that you don't need to care about things like that.
[...] but it is how it is done in all other major programming languages.
Only other languages don't require you to manually keep track of a correspondence between lightweight and heavyweight threads.
Since the haskell function is called via a callback, I guess that "threadsafe"
should also apply to "wrapper" functions -- that is, when the foreign world
calls haskell, we use another OS thread to run the haskell code.
Sorry, no clue what you mean... could you elaborate? "threadsafe" just applies to imports, not to exports and wrappers. "bound" applies to exports and wrappers, but not to imports. Should it be different?
Cheers,
Wolfgang
_______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
