Add MVar.modify?

[scf37]

Similar to Ref.modify, but using pessimistic lock.

It is very useful to guard shared state where state modification is effectful.

  /**
   * Atomically modify existing MVar value of type `S`, returning computed value of type `A`.
   *
   * @param v MVar to use
   * @param f MVar value modification function, returning new value and additional result
   * @tparam F effect to use
   * @tparam S MVar value type
   * @tparam A computed value type
   * @return computed value or error if `f` failed
   */
  private def modify[F[_], S, A](v: MVar[F, S])(f: S => F[(S, A)])(implicit B: Bracket[F, Throwable]): F[A] =
    v.take.flatMap { st =>
      B.guarantee(f(st).flatMap { case (st2, a) =>
        v.put(st2).map(_ => a)
      })(v.tryPut(st).void)
    }

[kailuowang]

You might want to submit it to the cats-effect instead

[scf37]

Opps, wrong repo indeed

[rossabaker]

Moved to the correct repo and reopened.

[scf37]

Really, I do not think it is good idea anymore. This is non-reentrant and therefore very error prone.

Correct reentrant implementation of RefM allowing S => F[S] updates is complicated and likely can not be done on MVar.

Feel free to close this.

[SystemFw]

as it stands, the implementation is not safe:
v.take.flatMap means you can be interrupted after take, which would leave the MVar in an inconsistent state. if you take.bracket, now take is not interruptible, which isn't good either.

Until we have something like what I proposed in #681
this is going to be hard. We do have a safe version in Semaphore#withPermit which you can use to guard a Ref

[SystemFw]

The other thing worth mentioning is that while "shared state with lock" is easy for simple cases (and you can use Semaphore + Ref to get there) for more complex logic using Ref + Deferred instead tends to be way more easily correct and behave better wrt interruption, if not as easy to get into at first.

[rossabaker]

Closing for now. Good conversation for the archives in case we revive it after something like #681.