Logs: liberachat/#haskell
| 2026-04-10 13:29:11 | × | mulk quits (~mulk@pd95147f8.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2026-04-10 13:29:23 | → | benkard joins (~mulk@pd95147f8.dip0.t-ipconnect.de) |
| 2026-04-10 13:29:42 | × | monochrom quits (trebla@216.138.220.146) (Ping timeout: 244 seconds) |
| 2026-04-10 13:29:43 | monochrm | is now known as monochrom |
| 2026-04-10 13:29:47 | benkard | is now known as mulk |
| 2026-04-10 13:29:54 | pavonia_ | is now known as pavonia |
| 2026-04-10 13:30:11 | → | divlamir joins (~divlamir@user/divlamir) |
| 2026-04-10 13:30:44 | × | xff0x quits (~xff0x@138.64.112.96) (Ping timeout: 244 seconds) |
| 2026-04-10 13:30:58 | → | ft joins (~ft@p508db287.dip0.t-ipconnect.de) |
| 2026-04-10 13:32:34 | → | xff0x joins (~xff0x@2405:6580:b080:900:e257:4447:f172:94ba) |
| 2026-04-10 13:34:52 | × | CiaoSen quits (~Jura@p549cbfb1.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2026-04-10 13:35:08 | → | pavonia_ joins (~user@user/siracusa) |
| 2026-04-10 13:36:25 | × | pavonia quits (~user@user/siracusa) (Ping timeout: 244 seconds) |
| 2026-04-10 13:36:49 | pavonia_ | is now known as pavonia |
| 2026-04-10 13:36:54 | → | CiaoSen joins (~Jura@p549cbfb1.dip0.t-ipconnect.de) |
| 2026-04-10 13:43:05 | → | pavonia_ joins (~user@user/siracusa) |
| 2026-04-10 13:45:12 | × | CiaoSen quits (~Jura@p549cbfb1.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2026-04-10 13:45:12 | × | pavonia quits (~user@user/siracusa) (Ping timeout: 244 seconds) |
| 2026-04-10 13:45:35 | pavonia_ | is now known as pavonia |
| 2026-04-10 13:47:06 | → | CiaoSen joins (~Jura@p549cbfb1.dip0.t-ipconnect.de) |
| 2026-04-10 13:55:04 | × | srazkvt quits (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2026-04-10 14:02:46 | × | Square3 quits (~Square@user/square) (Ping timeout: 244 seconds) |
| 2026-04-10 14:07:54 | × | CiaoSen quits (~Jura@p549cbfb1.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2026-04-10 14:14:27 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 2026-04-10 14:15:28 | × | czan quits (~czan@user/mange) (Quit: Zzz...) |
| 2026-04-10 14:25:09 | → | tromp joins (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) |
| 2026-04-10 14:29:39 | <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:30:14 | <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:31:03 | <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:31:24 | <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:55 | <tomsmeding> | Can this be avoided, or alternatively, is it impossible for an asynchronous exception to be delivered in that interval? |
| 2026-04-10 14:35:26 | <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#accept ) |
| 2026-04-10 14:36:16 | <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:38:03 | <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:38:25 | <tomsmeding> | (since accept() blocks in a foreign call, and foreign calls can't be interrupted with an asynchronous exception anyway) |
| 2026-04-10 14:39:33 | <geekosaur> | you might want https://flora.pm/packages/@hackage/safe-exceptions or UnliftIO |
| 2026-04-10 14:39:39 | <tomsmeding> | I'm in IO |
| 2026-04-10 14:39:54 | <tomsmeding> | so I don't need to unlift anything |
| 2026-04-10 14:40:13 | <int-e> | tomsmeding: Yeah I don't think the `unmask` is buying you anything useful here, in terms of interruptibility. |
| 2026-04-10 14:40:28 | <tomsmeding> | yeah I think I talked myself into the proper solution in the end |
| 2026-04-10 14:40:55 | <int-e> | (I was about to write something similar to what you wrote.) |
| 2026-04-10 14:41:13 | <tomsmeding> | cool, thank you for being my rubber duck |
| 2026-04-10 14:41:21 | <tomsmeding> | I just packed all of mine (I'm moving), so I needed you guys |
| 2026-04-10 14:41:30 | <int-e> | quack |
| 2026-04-10 14:41:36 | <tomsmeding> | :D |
| 2026-04-10 14:42:00 | <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:42:19 | <geekosaur> | (because it's a prerequisite for getting UnliftIO right) |
| 2026-04-10 14:43:37 | → | danza joins (~danza@user/danza) |
| 2026-04-10 14:49:21 | <tomsmeding> | relatedly: is Control.Concurrent.STM.atomically an interruptible operation? |
| 2026-04-10 14:50:00 | <tomsmeding> | (and if it throws, or lets through, an asynchronous exception, can I assume that the transaction has failed?) |
| 2026-04-10 14:52:32 | × | tromp quits (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-10 14:53:27 | <int-e> | STM transactions that don't retry are not interruptible |
| 2026-04-10 14:53:38 | <tomsmeding> | but it has a literal retry in it :p |
| 2026-04-10 14:53:47 | × | bggd quits (~bgg@user/bggd) (Remote host closed the connection) |
| 2026-04-10 14:53:49 | <tomsmeding> | (that's why I'm using STM here) |
| 2026-04-10 14:54:06 | <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:54:59 | → | rekahsoft joins (~rekahsoft@bras-base-orllon1103w-grc-20-76-67-111-168.dsl.bell.ca) |
| 2026-04-10 14:55:39 | <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:55:50 | <tomsmeding> | right |
| 2026-04-10 14:56:14 | <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:56:22 | <tomsmeding> | perfect |
| 2026-04-10 14:57:17 | <int-e> | ("bubbles up" -- it can also hit `orElse` and that doesn't make things interruptible) |
| 2026-04-10 14:57:26 | <tomsmeding> | yes makes sense |
| 2026-04-10 14:57:41 | <int-e> | Partly based on https://stackoverflow.com/questions/78132502/is-retry-using-stm-action-guaranteed-interruptible-in-ghc-haskell |
| 2026-04-10 14:58:11 | <int-e> | (mostly for confirmation, but the `orElse` details didn't occur to me) |
| 2026-04-10 15:07:04 | → | jmcantrell_ joins (~weechat@user/jmcantrell) |
| 2026-04-10 15:19:51 | → | tromp joins (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) |
| 2026-04-10 15:26:49 | → | driib3180 joins (~driib@vmi931078.contaboserver.net) |
| 2026-04-10 15:26:50 | → | karenw joins (~karenw@user/karenw) |
| 2026-04-10 15:34:49 | × | danza quits (~danza@user/danza) (Remote host closed the connection) |
| 2026-04-10 15:36:29 | × | driib3180 quits (~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat) |
| 2026-04-10 15:38:45 | → | driib3180 joins (~driib@vmi931078.contaboserver.net) |
| 2026-04-10 15:43:28 | → | somemathguy joins (~somemathg@user/somemathguy) |
| 2026-04-10 15:48:51 | → | eldritch-cooklie joins (~eldritch-@user/eldritch-cookie) |
| 2026-04-10 15:51:37 | → | emaczen joins (~user@user/emaczen) |
| 2026-04-10 15:53:21 | jmcantrell_ | is now known as jmcantrell |
| 2026-04-10 15:59:15 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 2026-04-10 16:00:43 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2026-04-10 16:00:59 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2026-04-10 16:06:59 | × | jmcantrell quits (~weechat@user/jmcantrell) (Ping timeout: 245 seconds) |
| 2026-04-10 16:25:37 | × | Googulator64 quits (~Googulato@team.broadbit.hu) (Ping timeout: 245 seconds) |
| 2026-04-10 16:28:31 | → | weary-traveler joins (~user@user/user363627) |
| 2026-04-10 16:36:28 | × | puke quits (~puke@user/puke) (Ping timeout: 250 seconds) |
| 2026-04-10 16:38:11 | × | sord937 quits (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2026-04-10 16:39:05 | → | Pozyomka_ joins (~pyon@user/pyon) |
| 2026-04-10 16:39:16 | × | Pozyomka quits (~pyon@user/pyon) (Ping timeout: 276 seconds) |
| 2026-04-10 16:41:06 | × | tromp quits (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-10 16:44:19 | × | takuan quits (~takuan@d8D86B9E9.access.telenet.be) (Remote host closed the connection) |
| 2026-04-10 16:45:31 | → | takuan joins (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-04-10 16:54:18 | → | jmcantrell_ joins (~weechat@user/jmcantrell) |
| 2026-04-10 16:54:25 | jmcantrell_ | is now known as jmcantrell |
| 2026-04-10 16:54:28 | × | jmcantrell quits (~weechat@user/jmcantrell) (Client Quit) |
| 2026-04-10 16:54:44 | → | jmcantrell joins (~weechat@user/jmcantrell) |
| 2026-04-10 16:57:43 | × | gmg quits (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2026-04-10 16:57:52 | → | gmg joins (~user@user/gehmehgeh) |
| 2026-04-10 16:59:17 | → | tromp joins (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) |
| 2026-04-10 17:03:52 | × | tromp quits (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) (Client Quit) |
| 2026-04-10 17:17:29 | → | tromp joins (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) |
| 2026-04-10 17:32:01 | × | eldritch-cooklie quits (~eldritch-@user/eldritch-cookie) (Ping timeout: 244 seconds) |
| 2026-04-10 17:35:06 | × | jmcantrell quits (~weechat@user/jmcantrell) (Ping timeout: 268 seconds) |
All times are in UTC.