Async Control Flow

This page summarizes the projects mentioned and recommended in the original post on /r/haskell
#Control #Conduit #Database #Postgresql

Our great sponsors
  • Onboard AI - Learn any GitHub repo in 59 seconds
  • InfluxDB - Collect and Analyze Billions of Data Points in Real Time
  • Revelo Payroll - Free Global Payroll designed for tech teams
  • SonarLint - Clean code begins in your IDE with SonarLint
Our great sponsors

  • pool-conduit

    Persistence interface for Haskell allowing multiple storage methods.

    I don't think connection is returned to the pool here. The thread is interrupted when query is sent to server, but before the results are consumed. At that point cleanup action catches `ThreadKilled` exceptions and issues `ROLLBACK`, which fails with `libpg` exception because the previous operations was not completed. And now cleanup action rethrows the `libpg` exception instead of the `ThreadKilled` one - that's the behavior of `bracket` from `base`. [The fix](https://github.com/yesodweb/persistent/pull/1207/files#diff-f9d7f232cd00cb88188b7fcc68110e3f4cb378fcad9df652360de44d13cd86e3R199) was to use `bracket` from `unliftio`, which [rethrows the correct exception](https://hackage.haskell.org/package/unliftio-0.2.14/docs/src/UnliftIO.Exception.html#bracket).

  • exceptions

    mtl friendly exceptions

    I see. Do you think rethrowing the original exception is the the right approach in all cases, or only in this case? In the documentation I wrote for the exceptions package, I recommend to let the release block's exceptions take priority, to match base's behavior. Should I recommend the opposite?

  • Onboard AI

    Learn any GitHub repo in 59 seconds. Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at www.getonboard.dev.

  • safe-exceptions

    Safe, consistent, and easy exception handling

    In safe-exception and uniftio it was decided to rethrow the original exception exactly because they decided to use uninterruptibleMask, see here for details.

  • postgresql-simple

    Mid-level client library for accessing PostgreSQL from Haskell

    Hmm, you are right, the bracket I pointed to is unrelated. I guess the fix is in catchAny, which doesn't catch ThreadKilled. So not it's not rolling the transaction back in case of asynchronous exceptions. My point is that it probably should not rollback even on synchronous exception. BTW the issue is well know, see for example here

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts