Re: Questions on the RTS C API regarding threads and tasks

Il giorno 09 nov 2015, alle ore 00:17, Edward Z. Yang 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