Protect raw Ptr (interior mutability) in static/dynamic effects

[ruifengx]

I am working on an application that requires binding to external C libraries. To be expected, the bound API works with raw Ptrs with interior mutability. I want make some context Ptrs available through some effects (by putting them in the StaticRep), so that the caller does not need to pass the contexts around manually. However, from my understanding of the library, when concurrency is used somewhere in the effect stack, StaticReps are shared among children threads, which would result in race conditions.

I think the proper way to protect against this accidental sharing is to use an MVar and always takeMVar before use (e.g., through modifyMVar) to claim unique ownership (like in Effectful.State.Static.Shared), but I am afraid this incurs some additional overhead, especially if the effect operation itself is cheap. Is there a way to mark an effect unsafe for concurrency, just like the SideEffects marker?

On the other hand, if I use dynamic effects (using interpret or reinterpret), how do I protect against sharing and race conditions? Is there a way to ensure that I use the correct version of effect handlers that protect against concurrency, when concurrency is used? Or is there a way to prevent concurrency handlers to be applied, after effects unsafe for concurrency are already interpreted?

[arybczak]

However, from my understanding of the library, when concurrency is used somewhere in the effect stack, StaticReps are shared among children threads, which would result in race conditions.

Yes, if you use evalStaticRep. But if you look at its definition:

evalStaticRep e m = unsafeEff $ \es0 -> do
  inlineBracket
    (consEnv e dummyRelinker es0)
    unconsEnv
    (\es -> unEff m es)

It passes to consEnv a dummyRelinker that does nothing. You can use this definition inline in your effect, but pass a custom relinker that will either make a copy of the data Ptr points or if you want to forbid cloning the effect, you can just use the error call in the relinker. That will just give you an error at runtime whenever you try to clone the environment, sadly there is no way to statically guarantee that an effect can't be cloned. At least if you use version 2.4.0.0 from master branch (to be released soon), an error call in the relinker will give you a nice call stack pointing to the location of the cloning attempt.

I think the proper way to protect against this accidental sharing is to use an MVar and always takeMVar before use (e.g., through modifyMVar) to claim unique ownership (like in Effectful.State.Static.Shared), but I am afraid this incurs some additional overhead

It does, the question is whether it actually matters. Benchmarks show that access to a state via MVar is about twice as slow than without it (dynamic/local vs dynamic/shared), but that's a microbenchmark, so take it with a grain of salt.

On the other hand, if I use dynamic effects (using interpret or reinterpret), how do I protect against sharing and race conditions?

If you make a static effect with a custom relinker, you can use it in a reinterpret.

[ruifengx]

Wow, thanks for the quick reply! I think I need to read the documentation about relinkers to know better about them. Having runtime errors are already better than silent misbehaviour; I just wanted to guarantee the soundness of the effect. Regarding MVars, I have to admit that I have not done any benchmarks to measure the actual performance difference, but I do think it is harder to use correctly (more things to worry about).

[ruifengx]

By the way, speaking of the benchmark, I think it makes sense to also include a figure with mtl/fused-effects/polysemy (the slowest three) removed, so that the difference in the fastest entries (effectful & cleff) are more pronounced. But it might also be intentional (to indicate that the difference in the fastest options generally does not matter).

[ruifengx]

Okay, I quickly skimmed through the code around relinkers. I think the forall es. Env es -> IO (Env es) is for transforming the Env in Handlers, which are specific to dynamic effects, so if I use static effects, it can be ignored. Then what I really need to worry about is the rep e -> IO (rep e) part, which should do a deep copy of my Ptrs or throw an error.

Now I only have one remaining question: do I also get an opportunity to clean up the extra clone? In my case, the finalisation is done in the handler itself, but it only get one copy of its StaticRep, so presumably all the other copies in the children threads would be leaked. Usually, we can use ForeignPtr and rely on GC to perform the finalisation, but it is unfortunately not possible in my case because the GC finalisation order is unspecified, and the library (FreeType) segfaults if objects are finalised in the incorrect order.

[arybczak]

do I also get an opportunity to clean up the extra clone?

Unfortunately not, there's no support for manual cleanup of such resources, you need to rely on GC 😞

[ruifengx]

Okay, thanks! I think I will just go with disallowing the copy altogether by throwing in the relinker.