What's ki's policy on resources that go out of scope whilst thread is still running?

[tomjaguarpaw]

What's ki's policy on resources that go out of scope whilst a thread is still running?

ki's approach to structured concurrency is very nice because it is strictly more general than async's withAsync whilst maintaining a number of desirable invariants. However, that generality does also allow some pathological behaviour that is impossible in withAsync.

Consider the program below. I open a scoped block, then a withFile block to obtain a Handle, and then forked a thread that uses the Handle. However, it's possible for the withFile block to finish before the thread has finished using the Handle, leading to a run time error.

There are some possible responses I can think of

• "withFile isn't safe anyway, so it doesn't matter"

  True, but withFile does have some guarantees, such as, if the body returns (), and it only ever launches threads with withAsync, then the Handle doesn't leak. (A version of withAsync for Bluefin would do even better.)

• "You can see that a Scope obtained outside withFile is used within withFile, which is obviously dangerous"

  True. It is a nice property of ki that you can observe this syntactically. (It's a style that Bluefin uses too.)

So does ki have a particular policy around this? Maybe it's

Don't use a Scope obtained outside a resource-acquiring block within that block

That seems fine. I guess it's disappointing that the most general concurrency construct I know of that doesn't have this problem (withAsync) is so much less general, but perhaps that's just life.

#!/usr/bin/env cabal
{- cabal:
  build-depends: base, ki, stm
-}
{-# LANGUAGE GHC2021 #-}

import Control.Concurrent (threadDelay)
import Control.Monad.STM (atomically)
import Ki (await, fork, scoped)
import System.IO (IOMode (WriteMode), hPutStr, withFile)

main :: IO ()
main = scoped $ \scope1 -> do
  putStrLn "Entering withFile block"
  withFile "/dev/null" WriteMode $ \h -> do
    putStrLn "Forking thread"
    fork scope1 $ do
      threadDelay 100_000
      putStrLn "Trying to write to the handle"
      hPutStr h ""

    putStrLn "Leaving withFile block"

  threadDelay 1_000_000

Entering withFile block
Forking thread
Leaving withFile block
Trying to write to the handle
cabal-script-test28.hs: /dev/null: hPutStr: illegal operation (handle is closed)

[mitchellwrosen]

👋 Hi, let's see...

I'm not sure there's much we can do in ki here. Many programs involving resources with "lifetimes" (that, by the way, don't just transition state when coming into or going out of scope – consider that hClose could be called by any thread at any time) either need to be written with care using simple types (my preferred solution), or could conceivably be written with some complicated "kleisli arrows of outrageous fortune"-type solution, session types, or some other unwieldly thing.

Don't use a Scope obtained outside a resource-acquiring block within that block

That sounds right, but I'm not yet sure it is necessary to go that far. Suppose we only say "take care to ensure resources are valid for the duration of any forked threads" but not actually disallow programs like your example. Do we gain anything by taking that stance?

Or, put differently, does your example program (or any other example program you can think of) actually need to sequence the resources in this way:

scoped \scope -> do
  withThing \thing -> do
    ...

rather than:

withThing \thing -> do
  scoped \scope -> do
    ...

If not, then yeah, I'd agree with "Don't use a Scope obtained outside a resource-acquiring block within that block" :)

[tomjaguarpaw]

Thanks! Good point about hClose taking the resource away regardless. That point, plus the question about the ordering of withThing versus scope, prompts me to try to ask the question I really wanted to ask, but didn't really know how to express. I still don't know, but I think I'm closer. Here goes:

There is at least one resource we know whose lifetime exactly corresponds to the period in which execution is within its "bracket": a ki Scope! We could imagine a program that forks a thread in an "outer scope" instead of an "inner" one, something like

scoped \scope1 -> do
  fork scope1 do
    scoped \scope2 -> do
      fork scope2 do
        -- call this thread "T"
        stuff

        fork scope1 do
          -- This thread will continue to
          -- run even when its "parent
          -- thread", T, has terminated.
          something

Now something can access stuff (good and natural) even when thread T has already terminated (which seems strange). Unlike withAsync, ki allows us to create a thread belonging to an "outer scope" within an "inner thread" scope. Is this OK? Perhaps. It seems that ki's approach is to assign threads to Scopes, not to "parent threads". So, I don't know any particular reason this is bad. My withFile example was the closest I managed to come to finding something that goes wrong with the very flexible notion of Scope provided by ki but it's not a very compelling example. But still, there's something that makes me feel uneasy about the flexibility of using Scopes.

Anyway, I don't think I have a particular point. I'm just vaguely hinting at some intuition I have and wondering if it aligns with what anyone else is thinking.

A concrete question

I'll follow up with a simpler concrete question: is there a good example of something that ki can do that withAsync can't? (I wondered if the happy eyeballs problem was such an example, but actually I think I see how to implement it with async's race (which can be derived from withAsync).)

[mitchellwrosen]

is there a good example of something that ki can do that withAsync can't?

I do think Happy Eyeballs is a good example, but by all means share an async-based solution if you'd like, so we can compare.

withAsync just associates each scope with precisely one thread. Here I've drawn the main thread along the bottom in black, an a withAsync-induced scope in red, with the associated thread also in black that runs alongside it to show they are linked. The red area delimits the lifetime of that one thread.

ki doesn't spawn a thread with a scope. Instead, the scope is created independent of any thread, after which any thread can be spawned "into" it, delimiting its life to the life of the scope.

So, they're both rather similar, but IMO it's a lot easier to create a dynamic number of helper threads with ki (as in the Happy Eyeballs example), as the strict relationship between thread-lifetime and scope-lifetime that you get with withAsync gets in the way.

Another minor difference: race spawns two threads, but the ki-flavored race only needs to spawn one (because the main thread can act as the second).

[tomjaguarpaw]

I do think Happy Eyeballs is a good example, but by all means share an async-based solution if you'd like, so we can compare.

See below. The Ki version is undoubtedly neater but

1. I'm sure the Async version can be made neater too, perhaps with some ContT
2. I'm more interested in what is expressible in principle rather than in syntactic awkwardnesses around expressing (which can often be worked around)

{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE BlockArguments #-}

import Control.Concurrent
import Control.Concurrent.Async (withAsync, wait)
import Control.Monad (when)
import Data.Maybe (isJust)

staggeredSpawner :: [IO ()] -> IO ()
staggeredSpawner [] = pure ()
staggeredSpawner (x : xs) =
  withAsync
    (threadDelay 250_000 *> staggeredSpawner xs)
    (\thread -> x *> wait thread)

happyEyeballs :: [IO (Maybe a)] -> IO (Maybe a)
happyEyeballs actions = do
  resultVar <- newEmptyMVar

  let worker action = do
        result <- action
        when (isJust result) do
          _ <- tryPutMVar resultVar result
          pure ()

  withAsync
    ( do
        staggeredSpawner (map worker actions)
        tryPutMVar resultVar Nothing
    )
    (\_ -> takeMVar resultVar)

Another minor difference: race spawns two threads, but the ki-flavored race only needs to spawn one (because the main thread can act as the second).

Hmm, I'm not sure what you mean here. If you're only spawning one thread withAsync is equivalent to the combination of scoped and fork so I don't see how Ki can be more powerful.

[mitchellwrosen]

Ah, my apologies, I misunderstood your question. I'm not aware of any fundamental advantage ki-style structured concurrency has over nested withAsync. I think it's a matter of style.

You may like reading this blog post. I think it essentially captures the distinction we are talking about here, where libdill plays the role of ki and trio plays the role of nesting withAsync: https://250bpm.com/blog:139/index.html

Regarding race, I was just mentioning a minor difference between an async race and a ki race, because you said that you anticipate being able to write Happy Eyeballs with race. But I was actually confusing race and concurrently, so nevermind :)

[tomjaguarpaw]

Regarding race, I was just mentioning a minor difference between an async race and a ki race, because you said that you anticipate being able to write Happy Eyeballs with race

Oh, well I'm not even sure what Ki race is! I don't see a function with that name, anyway. But in any case, I forgot to write my happy eyeballs using race 😆

Thanks for the literature references. I should do some reading up on structured concurrency.

[mitchellwrosen]

Ah, apologies again, I was just referring to the way one might write a race or concurrently combinator with ki, without much cleverness:

concurrently :: IO a -> IO b -> IO (a, b)
concurrently action1 action2 =
  Ki.scoped \scope -> do
    thread1 <- Ki.fork scope action1
    result2 <- action2
    result1 <- atomically Ki.await thread1
    pure (result1, result2)

race :: IO a -> IO a -> IO a
race action1 action2 =
  Ki.scoped \scope -> do
    resultVar <- newEmptyMVar
    _ <- Ki.fork scope (action1 >>= tryPutMVar resultVar)
    _ <- Ki.fork scope (action2 >>= tryPutMVar resultVar)
    takeMVar resultVar

Since the definitions are so much smaller than those found in async, I figured they aren't worth adding to the API proper.

And yeah, that particular blog has some interesting information! Let me know if you find any other good reads during your research.

[tomjaguarpaw]

Ah got it, yes, I agree it doesn't make a lot of sense to add them to the API. I'm somewhat surprised that async has them explicitly, actually.

Let me know if you find any other good reads during your research.

Will do!