On 29 March 2006 14:35, John Meacham wrote:
On Wed, Mar 29, 2006 at 02:05:35PM +0100, Simon Marlow wrote:
What you are suggesting is that there may be implementations that do not support reentrant/blockable, but do support the others. And in that case, of course you really need to know the difference between blockable and reentrant. I'm just not sure the standard should allow such implementations.
It would be a very odd thing to disallow, seeing as how it would rule out or at least place fairly large implementation restrictions on yhc,hugs and jhc and not a single foreign import in the standard libraries needs to be 'blockable reentrant' as far as I can tell.
though, I do need to look at hugs and yhcs source more carefully to know whether that is the case for sure. it depends on a lot of implementation details and how they handle OS-level threads and blockable in general.
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. Cheers, Simon
here's another possible way to look at the complexities, and interactions of FFI and Haskell' concurrency: - we've been told here that concurrency is just a library - GHC implements such a library - all Haskell' implementations will support FFI - FFI allows GHC to export that concurrency library - FFI allows other Haskell' implementations to import that library ==> all Haskell' implementations can support GHC-style concurrency even if that looks like one of those 0==1 proofs, it might still be worthwhile to discuss this as a concrete example, to highlight the difficulties?-) cheers, claus
Hi
- we've been told here that concurrency is just a library No, its not. The interface to concurrency is just a library, but internally certain things in the runtime have to change.
- FFI allows other Haskell' implementations to import that library If all Haskell' prime implementations depend on "GHC the library", then do we really have many Haskell' prime implementations, or just a pile of wrappers around GHC?
Thanks Neil
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⑈
participants (4)
-
Claus Reinke -
John Meacham -
Neil Mitchell -
Simon Marlow