Questions on the RTS C API regarding threads and tasks

Edward Z. Yang ezyang at
Sun Nov 8 23:17:25 UTC 2015

Excerpts from Nicola Gigante's message of 2015-11-04 23:13:51 -0800:
> We don't have measurements, but we ruled out this possibility for
> performance reasons. Our idea is to make a thin Haskell wrapper 
> around a tiny bit of highly optimized C code. What's the performance
> of locking on MVars?

I still don't know what it is you're trying to do.  If you have a tiny
bit of optimized C code that runs quickly, then you should just make
an unsafe FFI call to it (as for as Haskell's runtime is concerned,
it's just a "fat instruction").

> While we are at it: are primops callable directly from C? I suppose
> calling conventions are different.

Anything is "callable" from C, but yes, you have to do the right
calling convention.  Primops are not easily callable from C.

> A question comes to mind: you mentioned "safe" calls. 
> Are unsafe calls different regarding the detaching of the capability?

An unsafe call does not detach the capability.

> Also: would a patch to make this possible be accepted?
> In particular:
> - add a way to make a "ultraunsafe" foreign call that do not loose the
>   ownership of the calling thread. 

I don't see what the difference between this and an unsafe foreign call

> - add a BlockedOnExplicitSleep flag for tso->why_blocked
>   (And in turn this means managing a different blocking queue, right?)
> - export something to reliably put in sleep and resume threads
>   in this way.
> Is this feasible? Would it be a good idea?

I still don't see why you can't just block the thread on an MVar
(removing it from the main run queues), and then when you want to
resume it write to the MVar.  It'll have an added bonus that you'll
automatically handle masking/async exceptions correctly.

If you find the MVar implementation is too slow, then maybe you
can think about making an optimized implementation which doesn't
use any synchronization / is inline in the TSO so no allocation
is necessary.  But in my opinion this is putting the cart before
the horse.


More information about the ghc-devs mailing list