FFI, safe vs unsafe

[John Meacham]

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⑈