Idea: Managed resource map

[djspiewak]

trait Manager[F[_], K, V] {

  def +=(pair: (K, Resource[F, V])): F[Unit]

  def -=(key: K): F[Unit]

  def apply(key: K): F[Option[V]]

  def join(key: K): F[V]
}

object Manager {
  def apply[F[_]: Sync, K, V]: Resource[F, Manager[F, K, V]] = ???
}

The idea here is that it's often useful to have a concurrent map-like data structure which manages Resource lifecycles for you, indexed by some key (so you can retrieve the results). These resources can be submitted (via +=) and will be evaluated in background, with their value stored in the map once complete. Removing the key from the map would close the resource scope. Similarly, closing the resource scope on the Manager would close all constituent Resources and cancel any outstanding computations.

[SystemFw]

and will be evaluated in background, with their value stored in the map once complete.

should this allow cancellation? What happens if the evaluation fails?

[kubukoz]

and will be evaluated in background, with their value stored in the map once complete.

should this allow cancellation? What happens if the evaluation fails?

It would only be cancelable by -= or closing the Manager, I think. If it fails, I would probably fail apply and join's effects. That is, if I understand join correctly (apply + getOrElse raise?)

[RaasAhsan]

Should failing remove the entry from the map, or should that be pushed back to the user? I could see it trying to acquire the Resource again.

I think this might be a case where we want to designate V as being thread-safe, since multiple fibers can trivially access the same resource, or should that be forbidden?

[djspiewak]

should this allow cancellation?

Yes

What happens if the evaluation fails?

Right now, the interface doesn't have a good channel for that. The key/value pair would simply not be inserted into the map. Users could add their own side-channels by tossing an onError on the resource before insertion, or we could do something for them to allow for the reporting. Certainly I think that, if the user joins, it should be reported back to them. In fact, perhaps join should return an Outcome.

I think this might be a case where we want to designate V as being thread-safe, since multiple fibers can trivially access the same resource, or should that be forbidden?

I would definitely assume V has to be thread-safe. This kind of structure doesn't make much sense otherwise, imo.

[ChristopherDavenport]

This sounds a lot like keypool - https://github.com/ChristopherDavenport/keypool

[djspiewak]

I think you could implement keypool with this, but this is definitely a different thing. There are no bounds here, and the idea is specifically to submit Resources, rather than effects, because the point of such a construct would be to manage the still-open lifecycles of those resources until removed from the map.

[wemrysi]

I'll work on this if nobody minds, I've had need for something similar and it'd be nice to have a standard implementation.

[djspiewak]

@wemrysi I totally missed your comment. Take it. :-)