Newest at the top
| 2026-04-10 14:58:11 +0000 | <int-e> | (mostly for confirmation, but the `orElse` details didn't occur to me) |
| 2026-04-10 14:57:41 +0000 | <int-e> | Partly based on https://stackoverflow.com/questions/78132502/is-retry-using-stm-action-guaranteed-interruptible-in… |
| 2026-04-10 14:57:26 +0000 | <tomsmeding> | yes makes sense |
| 2026-04-10 14:57:17 +0000 | <int-e> | ("bubbles up" -- it can also hit `orElse` and that doesn't make things interruptible) |
| 2026-04-10 14:56:22 +0000 | <tomsmeding> | perfect |
| 2026-04-10 14:56:14 +0000 | <int-e> | So if you run `atomically` with exceptions masked... yeah getting an exception is only possible if the transaction hasn't succeeded yet. |
| 2026-04-10 14:55:50 +0000 | <tomsmeding> | right |
| 2026-04-10 14:55:39 +0000 | <int-e> | If the retry bubbles up to atomically, it blocks the thread waiting for some of the involved variables to change, so the thread becomes interruptible then. |
| 2026-04-10 14:54:59 +0000 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-20-76-67-111-168.dsl.bell.ca) rekahsoft |
| 2026-04-10 14:54:06 +0000 | <tomsmeding> | it's fine if it's interruptible, as long as I can assume that if it's interrupted, it failed |
| 2026-04-10 14:53:49 +0000 | <tomsmeding> | (that's why I'm using STM here) |
| 2026-04-10 14:53:47 +0000 | bggd | (~bgg@user/bggd) (Remote host closed the connection) |
| 2026-04-10 14:53:38 +0000 | <tomsmeding> | but it has a literal retry in it :p |
| 2026-04-10 14:53:27 +0000 | <int-e> | STM transactions that don't retry are not interruptible |
| 2026-04-10 14:52:32 +0000 | tromp | (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-10 14:50:00 +0000 | <tomsmeding> | (and if it throws, or lets through, an asynchronous exception, can I assume that the transaction has failed?) |
| 2026-04-10 14:49:21 +0000 | <tomsmeding> | relatedly: is Control.Concurrent.STM.atomically an interruptible operation? |
| 2026-04-10 14:43:37 +0000 | danza | (~danza@user/danza) danza |
| 2026-04-10 14:42:19 +0000 | <geekosaur> | (because it's a prerequisite for getting UnliftIO right) |
| 2026-04-10 14:42:00 +0000 | <geekosaur> | the reason I mentioned UnliftIO is that it also provides an exception API that, unlike the standard one, lets you ensure nothing leaks |
| 2026-04-10 14:41:36 +0000 | <tomsmeding> | :D |
| 2026-04-10 14:41:30 +0000 | <int-e> | quack |
| 2026-04-10 14:41:21 +0000 | <tomsmeding> | I just packed all of mine (I'm moving), so I needed you guys |
| 2026-04-10 14:41:13 +0000 | <tomsmeding> | cool, thank you for being my rubber duck |
| 2026-04-10 14:40:55 +0000 | <int-e> | (I was about to write something similar to what you wrote.) |
| 2026-04-10 14:40:28 +0000 | <tomsmeding> | yeah I think I talked myself into the proper solution in the end |
| 2026-04-10 14:40:13 +0000 | <int-e> | tomsmeding: Yeah I don't think the `unmask` is buying you anything useful here, in terms of interruptibility. |
| 2026-04-10 14:39:54 +0000 | <tomsmeding> | so I don't need to unlift anything |
| 2026-04-10 14:39:39 +0000 | <tomsmeding> | I'm in IO |
| 2026-04-10 14:39:33 +0000 | <geekosaur> | you might want https://flora.pm/packages/@hackage/safe-exceptions or UnliftIO |
| 2026-04-10 14:38:25 +0000 | <tomsmeding> | (since accept() blocks in a foreign call, and foreign calls can't be interrupted with an asynchronous exception anyway) |
| 2026-04-10 14:38:03 +0000 | <tomsmeding> | or is this whole design wrong and should I just not unmask, but instead run the accept() call in masked state and do an `allowInterrupt` afterwards to check if something happened in the meantime? |
| 2026-04-10 14:36:16 +0000 | <tomsmeding> | that mkSocket call (on the `new_sock <- ...` line) performs allocation, so it's an exception reception point as far as I know |
| 2026-04-10 14:35:26 +0000 | <tomsmeding> | (this is the function that is called: https://hackage-content.haskell.org/package/network-3.2.8.0/docs/src/Network.Socket.Syscall.html#a… ) |
| 2026-04-10 14:31:55 +0000 | <tomsmeding> | Can this be avoided, or alternatively, is it impossible for an asynchronous exception to be delivered in that interval? |
| 2026-04-10 14:31:24 +0000 | <tomsmeding> | I do get to run my cleanup in this case, but I don't have a socket, so I have a lingering socket open that was accepted but not closed |
| 2026-04-10 14:31:03 +0000 | <tomsmeding> | now from just reading Control.Exception documentation, it seems that it might be possible that this thread is killed _after_ `accept` has accepted a connection (and thus opened a socket for it), but _before_ it returns. |
| 2026-04-10 14:30:14 +0000 | <tomsmeding> | i.e. I want the `accept` call to be interruptible (because I'll be blocking there), but I want to know it if it went wrong and do some cleanup |
| 2026-04-10 14:29:39 +0000 | <tomsmeding> | suppose I'm writing a little TCP server, and I have a loop that calls accept() to accept connections. I want to be exception-safe and I have some locking going on around this, so I write `mask $ \unmask -> do .... ; unmask (accept sock) `onException` cleanup; ...` |
| 2026-04-10 14:25:09 +0000 | tromp | (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) |
| 2026-04-10 14:15:28 +0000 | czan | (~czan@user/mange) (Quit: Zzz...) |
| 2026-04-10 14:14:27 +0000 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2026-04-10 14:07:54 +0000 | CiaoSen | (~Jura@p549cbfb1.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2026-04-10 14:02:46 +0000 | Square3 | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2026-04-10 13:55:04 +0000 | srazkvt | (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2026-04-10 13:47:06 +0000 | CiaoSen | (~Jura@p549cbfb1.dip0.t-ipconnect.de) CiaoSen |
| 2026-04-10 13:45:35 +0000 | pavonia_ | pavonia |
| 2026-04-10 13:45:12 +0000 | pavonia | (~user@user/siracusa) (Ping timeout: 244 seconds) |
| 2026-04-10 13:45:12 +0000 | CiaoSen | (~Jura@p549cbfb1.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2026-04-10 13:43:05 +0000 | pavonia_ | (~user@user/siracusa) siracusa |