Newest at the top
| 2026-04-10 16:36:28 +0000 | puke | (~puke@user/puke) (Ping timeout: 250 seconds) |
| 2026-04-10 16:28:31 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-04-10 16:25:37 +0000 | Googulator64 | (~Googulato@team.broadbit.hu) (Ping timeout: 245 seconds) |
| 2026-04-10 16:06:59 +0000 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 245 seconds) |
| 2026-04-10 16:00:59 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-04-10 16:00:43 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2026-04-10 15:59:15 +0000 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2026-04-10 15:53:21 +0000 | jmcantrell_ | jmcantrell |
| 2026-04-10 15:51:37 +0000 | emaczen | (~user@user/emaczen) emaczen |
| 2026-04-10 15:48:51 +0000 | eldritch-cooklie | (~eldritch-@user/eldritch-cookie) eldritch-cookie |
| 2026-04-10 15:43:28 +0000 | somemathguy | (~somemathg@user/somemathguy) somemathguy |
| 2026-04-10 15:38:45 +0000 | driib3180 | (~driib@vmi931078.contaboserver.net) driib |
| 2026-04-10 15:36:29 +0000 | driib3180 | (~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat) |
| 2026-04-10 15:34:49 +0000 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-04-10 15:26:50 +0000 | karenw | (~karenw@user/karenw) karenw |
| 2026-04-10 15:26:49 +0000 | driib3180 | (~driib@vmi931078.contaboserver.net) driib |
| 2026-04-10 15:19:51 +0000 | tromp | (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) |
| 2026-04-10 15:07:04 +0000 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 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? |