On Wed, Mar 29, 2006 at 04:11:56PM +0100, Simon Marlow wrote:
Ok, let's explore how difficult it really is.
Take a single-threaded implementation that forks OS threads for concurrent foreign calls. Let's call the OS thread running Haskell code the "runtime thread". An OS thread wanting to call a foreign export must make an RPC to the runtime thread. You could do this by:
- have a channel for RPC requests
- the callee creates a condition var for the result, and sends the call details down the channel with the condition var.
- the runtime thread picks up the request in its event loop and forks a Haskell thread to handle it
- when the Haskell thread completes it places the result in the right place and signals the condition variable
- the callee picks up the result, frees the resources and continues on its merry way
can't be more than a couple of days work, unless I'm missing something? It's not particularly fast, but then call-ins in GHC aren't fast either.
still seems rather complicated for something that as far as I know has never come up as needed :) and given that, it is certainly unacceptable to pay that cost for every reentrant or blockable call on the off chance it might want to do both. Trading a single 'call' instruction for a condition variable, a rpc call, and some value passing and many memory accesess and potential SMP bus locks is more than just not particularly fast :) why are call-ins in ghc not very fast? with jhc they are just straight C function calls. I just make the appropriate haskell function with its arguments unboxed available and optimize like normal then don't put 'static' in front of it when spitting out the c code. now... 'wrapped' functions are a different beast. one I have not needed to solve yet and I don't look forward to it. but not particularly more expensive (one more call, a bit of stack rearrangement) just rather ugly. John -- John Meacham - ⑆repetae.net⑆john⑈