more primitives from Control.Concurrent.Async for CH

Description

I needed a Process-based version of the Concurrently applicative from Control.Concurrent.Async. To implement it, I had to do some trivial rewriting of a few primitives to work with Process instead of IO (code below). Would it make sense to include these functions in Control.Distributed.Process.Platform.Async (given that it's already largely modeled after Control.Concurrent.Async)?

By the way, I couldn't use CH's existing Async to implement these functions because those require the inner type be Serializable, and I wanted to be able to use these in an applicative, which requires that the inner type be unrestricted.

Environment

None

Activity

Show:
Tim Watson
April 10, 2014, 11:04 AM

Wouldn't this mean that one could use ... only when (a -> b) is Serializable (which basically never happens)?

Not sure. I was only proposing that the 'a' and the 'b' should be Serializable. As soon as I find some time to experiment, I'll take a look and see if there's something we can do that doesn't make the resulting typeclass unusable.

davidsd
April 3, 2014, 3:05 PM

I'm extremely far from a Haskell expert, so don't take my assertions too seriously . I'm not familiar with these kinds of context bounds on Applicative instances – I've never played around with them. Wouldn't this mean that one could use

only when (a -> b) is Serializable (which basically never happens)?

I'm not at all wedded to the particular implementation of these primitives, so alternatives are very welcome. Here's a bit more detail about what I'm using them for. I want to be able to write code that looks pure and have expensive computations automatically run remotely. To this end, I have a Monad/Applicative where Control.Applicative.(<*>) /= Control.Monad.ap – Applicative <*> is used for concurrent computations, while Monadic >>= is used for sequential computations. (This is similar to Haxl: http://www.reddit.com/r/haskell/comments/1le4y5/the_haxl_project_at_facebook_slides_from_my_talk). Right now, I have

This lets me do something like

Tim Watson
April 3, 2014, 1:45 PM

Oh, and the other problem with this implementation is that it only works on the local node. It would be nice if we could re-use the async infrastructure so this can be done with both the local and/or remote nodes.

AFAICT, the only barrier - performance considerations notwithstanding - to making it Async a -> Async b -> Process (Either a b) is that we'd need to add a Concurrently or Asynchronously newtype and provide an Applicative instance for it, somehow. Is it possible to do this without existential types? I would've though we could get away with:

Would that work?

Tim Watson
April 3, 2014, 1:39 PM

I needed a Process-based version of the Concurrently applicative from Control.Concurrent.Async. To implement it, I had to do some trivial rewriting of a few primitives to work with Process instead of IO (code below). Would it make sense to include these functions in Control.Distributed.Process.Platform.Async (given that it's already largely modeled after Control.Concurrent.Async)?

Well, I like what they do and think it would make sense to include them somewhere, but I'm not sure where (yet). I don't know if we should take them verbatim either - it depends on what semantic guarantees we want to support.

I suppose the thing that makes these seem a little odd is that they don't use the Async API at all, but they're probably quite a bit faster (and less resource intensive) than {{withAsync left .... withAsync right }} versions would be, for the same reasons as 's thread based package.

Perhaps if we put them at the top level (in Async.hs) that would be the best home for them.

One thing that concerns me is that we `catchAll` in both cases, so an exit signal sent to either worker will lead to it terminating normally rather than with the given exit reason. That could make it hard, though not impossible, to use these processes within a supervision tree, for the reasons outlined in http://haskell-distributed-next.github.io/tutorials/3ch.html#process_lifetime and http://haskell-distributed-next.github.io/tutorials/5ch.html (sorry, the latter is still incomplete).

I'll have a ponder about that, but overall, I like what these do and have wanted to bring across more of 's API, so this will be a step towards doing that.

By the way, I couldn't use CH's existing Async to implement these functions because those require the inner type be Serializable, and I wanted to be able to use these in an applicative, which requires that the inner type be unrestricted.

Can we not add our own Concurrently (or Asynchronously perhaps) newtype and use that with applicative?

Assignee

Tim Watson

Reporter

davidsd

Labels

None

External issue ID

None

OS

Linux

Time tracking

0m

Time remaining

10m

Components

Affects versions

Priority

Minor