We'll see if I can finally get this message to post to the list...
"Manuel M. T. Chakravarty" wrote:
> Therefore, I propose to have three kinds of FFI calls:
>
> unsafe - as before
> safe - as currently implemented
> supersafe - (or call it "threadsafe" or "blocksafe")
> the solution you described above
>
> I think, the trouble of having to deal with three kinds of
> calls is worthwhile as
>
> (a) "unsafe" and "safe" can be part of a standard FFI;
> "supersafe" is only added by implementations that also
> support multi-threading;
> (b) bindings to non-thread-safe libraries can use "unsafe"
> and "safe"; in a multi-threaded RTS, they are, so to
> speak, included into the lock that protects the Haskell
> heap etc; and
> (c) if a programmer knows that a call cannot block, but may
> re-enter the Haskell scheduler, "safe" provides a faster
> way of doing the call.
I don't think that these three FFI types are enough to cover *all* of
the bases regarding callbacks, blocking, and thread-safety.
As a diabolical example, say that I really wanted a multithreaded GTK+
application. Say, for example, a ray-trace program where the tracing
engine is running on a separate thread than the GUI. The GUI updates the
display every few seconds and can stop, start, pause the engine
concurrently. Every GTK+ program calls gtk_main(), which won't return
until the program ends. It's conceptually vague whether or not to
classify gtk_main() as blocking or not, since it does invoke callbacks.
But at any rate, I want to keep the GTK+ FFI calls within a single OS
thread, because GTK+ is not terribly thread-safe, but I also want the
ray-tracing engine to run concurrently on a separate Haskell thread.
Which of the three types above would you use when defining gtk_main()?
Perhaps callback, blocking, and thread-safety should each be separate
boolean attributes. However, I'm not really sure what "thread-safe"
function means, within the Haskell FFI. It could be that no two
thread-safe functions can be executing at the same time. Or, it could
mean that any callbacks that a "thread-safe" function makes are run on
the same OS thread as that function. Perhaps thread-safety can be
further broken down into two different types?
I'm getting the feeling that we may be opening Pandora's Box here.
Surely, there must be a more elegant solution that resolves all of these
problems. If I come up with it, I'll let you know. :)
- Michael Hobbs
