AFAIK it’s really very very simple: a capability is just a glorified mutex lock. When you perform a safe FFI call, the Haskell code marshals Int’s, etc. into the HsInt etc. C equivalents, then releases the capability (the mutex lock). If there are no other worker threads, it launches another worker thread. Then it performs the FFI call.

Any return to Haskell code (either via the FFI C-to-Haskell, or a return from the safe FFI call) then attempts to lock the capability (mutex). The OS thread blocks until the capability (mutex) is unlocked by whoever got it.

My understanding is that the entire capability moves to another OS thread, and I don’t see why that would entail much overhead. In particular, you don’t have to move individual Haskell threads. If that were true, then the cost of a safe call would be linear in the number of Haskell threads, which would be unacceptable. You do have to save more state though, because (among other things?) you have to ensure that the garbage collector will find everything if the foreign code calls back into Haskell and triggers a GC.

That issue sounds like another post that is worth writing. Thanks!

I too have benchmarked safe versus unsafe calls. I used a safe and unsafe binding to a C function that added the two parameters it was passed, and used criterion. There may well be subtleties that this benchmark didn’t reveal, but that suggested the overhead to be on the order of 7 nanoseconds for an unsafe call or 100 nanoseconds for an safe call on my systems. So yes, if the call is going to take more than about a microsecond, then the overhead isn’t that big of a deal… but I’m not sure what the scheduling granularity of Haskell threads is supposed to approximate, either. I believe that’s not time based, but rather a counter that counts down as you pass through yield points, so I believe the granularity can depend on what you are doing.

Regarding memcpy, you can determine how much memory it’s going to copy based on the parameters, so you could have a simple Haskell wrapper that executes either a safe or unsafe call accordingly. You could even have GHC inline the wrapper and get rid of the branch in the case of constants.

Yield points are whenever allocation happens, but I don’t know anything about it beyond that.

Regarding memcpy, that’s such an obvious solution that I’m somewhat embarrassed I didn’t think of it. Thanks. :)

This happens because unsafe calls are basically just direct C function calls. Safe calls are that plus various book-keeping and thread juggling.

A difficulty is that how long a call takes frequently depends on its what its arguments are (or on other external state). memcpy could copy a byte, or a gigabyte. Is there any good solution to this other than importing both a safe and an unsafe version and leaving the choice to the client? If you use the function internally, you could end up needing to provide two versions of every function which uses it (per each such foreign import), so this doesn’t seem really tractable in the general case… I guess the only safe thing to do is to leave some performance on the table and always make safe calls when in doubt, and to only make unsafe ones when you can be sure they won’t block for too long.

Remi Turk was kind enough to do some benchmarks of safe calls vs. unsafe calls vs. his cinvoke library bindings a while back, with both the threaded and non-threaded runtimes:

http://www.haskell.org/pipermail/haskell-cafe/2011-March/090029.html
http://www.haskell.org/pipermail/haskell-cafe/2011-March/090083.html

The overhead of safe calls seems to be quite low for (presumably most) non-synthetic use cases.