Questions on the RTS C API regarding threads and tasks
nicola.gigante at gmail.com
Mon Nov 9 14:02:49 UTC 2015
> Il giorno 09 nov 2015, alle ore 00:17, Edward Z. Yang <ezyang at mit.edu> ha scritto:
> 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”).
I’m sorry, I know my description was too vague. The reason is that we have
a blind review pending on a paper and I had instructions of not to talk about
what we are doing. Anyway, your reply is nevertheless very clear.
>> 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.
Ok, that’s what I meant.
>> 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.
Ok, thanks for the confirmation of this fact.
>> 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
Nothing actually, I was confused about what “unsafe” call means.
>> - 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.
Yes, that seems simple and fast enough. You’re right that we should
measure before making assumptions about hypothetical poor performance.
Thank you for your help
More information about the ghc-devs