foreign-library: Which RTS to link against?

[treblacy]

Thank you for the foreign-library addition, it is pretty sweet, it makes my life easier as the author of Calling Haskell Shared Libraries from C (Linux) 😆

Currently it links against the unthreaded GHC RTS. So there is potential that one day someone has a multi-threaded C program that uses a Haskell library built this way, calls Haskell functions from multiple threads concurrently, and there will be a problem. (The unthreaded RTS detects reentrancy and simply aborts the whole program with a "schedule: re-entered unsafely" message.)

I am not sure what I request instead:

1. Add moar settings so a dev of a foreign-library can choose. But I'm not sure who is in the best position to choose, the Haskell foreign-library dev or the C program dev.

2. Link against the threaded RTS across the board. But I'm not sure this harms no one; I don't even know the statistics of how many people have to avoid the threaded RTS.

[23Skidoo]

/cc @edsko

[edsko]

/cc @dcoutts

[TravisWhitaker]

I'd like this feature too, and would lean towards option one. I think the Haskell library author should choose which RTS to link against, and if it's truly necessary to make this switchable a flag could be used.

I'm interested in how the plumbing works for the foreign-import stanza; I was a bit surprised when ghc-options: ... -threaded ... didn't work.

[treblacy]

I have a cunning plan! Produce both the unthreaded version and the threaded version.

[sergv]

Just my 2 cents: even if C part has no concurrency whatsoever, it may be nice to still link Haskell shared library with the threaded runtime so that it will do its job faster. In a way, such a C program could delegate all the parallelism into Haskell.