Questions on the RTS C API regarding threads and tasks

[Nicola Gigante]

> 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
> is.
> 

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

> Edward


Greetings,
Nicola