2025/09/07

Newest at the top

2025-09-07 12:04:24 +0200 <arahael> I did notice that. :P
2025-09-07 12:04:22 +0200 <Franciman> ski: can we have ontological modelling in haskell?
2025-09-07 12:04:18 +0200 <tomsmeding> but then the "Portability" field at the top of the docs has value "haha"... :p
2025-09-07 12:04:07 +0200 <tomsmeding> maaybe to have future compatibility with platforms where a pty is not a file descriptor?
2025-09-07 12:03:22 +0200 <tomsmeding> yeah good question
2025-09-07 12:02:31 +0200 <tomsmeding> which seems to implement the actual waiting by registering a callback on some kind of event; that callback does a putMVar, and the actual waiting is a takeMVar
2025-09-07 12:02:26 +0200 <arahael> (getFd is not exported in that module)
2025-09-07 12:02:20 +0200 <arahael> I was confused why I couldn't get the handle from it, though.
2025-09-07 12:02:09 +0200 <arahael> Ah, good.
2025-09-07 12:02:09 +0200 <tomsmeding> a few functions deep you end up here https://hackage.haskell.org/package/base-4.14.0.0/docs/src/GHC.Event.Thread.html#threadWait
2025-09-07 12:01:35 +0200 <tomsmeding> just looked at that suspiciously named threadWaitRead function; I'm 99% sure the "thread" referred to there is the Haskell-level forkIO thread
2025-09-07 12:00:37 +0200 <arahael> Nice having a real type system again.
2025-09-07 12:00:31 +0200 <arahael> I am. :) It's so refreshing.
2025-09-07 12:00:08 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-09-07 11:59:09 +0200 <tomsmeding> I hope you enjoy being here :)
2025-09-07 11:58:44 +0200 <arahael> Been ages since I've been here, actually, been out of the haskell space for a while. I miss it.
2025-09-07 11:58:28 +0200trickard_trickard
2025-09-07 11:58:16 +0200 <tomsmeding> please do
2025-09-07 11:58:11 +0200 <arahael> And if I am, then I'll be re-asking here to figure out what I'm doing wrong. :P
2025-09-07 11:57:59 +0200 <tomsmeding> cool, then you should forget about this particular bit :p
2025-09-07 11:57:50 +0200 <arahael> Nice, I'm not expecting to do anything 'tricky' at this stage.
2025-09-07 11:57:47 +0200segfaultfizzbuzz(~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds)
2025-09-07 11:56:30 +0200 <tomsmeding> they still don't block the OS thread on the scheduler level
2025-09-07 11:56:20 +0200 <tomsmeding> but they are non-interruptible _on the haskell level_, meaning that you need to reach for heavier-handed exception machinery to interrupt them
2025-09-07 11:56:00 +0200 <tomsmeding> there are also some operations on the haskell level that are "non-interruptible" ( https://hackage.haskell.org/package/base-4.21.0.0/docs/Control-Exception.html#g:12 ), which can be important if you do tricky things with concurrency and exceptions (and MVars, mostly)
2025-09-07 11:55:24 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-07 11:53:25 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-09-07 11:52:08 +0200 <arahael> Ah, cool.
2025-09-07 11:51:59 +0200segfaultfizzbuzz(~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz
2025-09-07 11:51:40 +0200 <tomsmeding> this one https://downloads.haskell.org/ghc/latest/docs/users_guide/using-optimisation.html#ghc-flag-fomit-y…
2025-09-07 11:50:20 +0200 <tomsmeding> yay :)
2025-09-07 11:50:13 +0200 <arahael> I think I can cross that bridge if I ever get to it, I think what I needed now was to sort of learn the more typical conventions, so you've been very helpful.
2025-09-07 11:49:59 +0200 <tomsmeding> if you suspect that this is causing you pain
2025-09-07 11:49:50 +0200 <tomsmeding> iirc there's an option to GHC that makes it insert more yields
2025-09-07 11:49:38 +0200 <arahael> Yeah, makes sense.
2025-09-07 11:49:33 +0200 <tomsmeding> (the runtime is kind of cooperatively scheduled)
2025-09-07 11:49:30 +0200 <arahael> I've heard about that.
2025-09-07 11:49:21 +0200 <tomsmeding> scheduler yields occur on allocation, so if you have a tight loop that doesn't allocate, it doesn't yield and it doesn't relinquish the OS thread
2025-09-07 11:48:54 +0200 <tomsmeding> arahael: there is one pernicious thing that blocks an OS thread in GHC haskell: a tight loop that doesn't allocate
2025-09-07 11:47:53 +0200 <arahael> :P
2025-09-07 11:47:49 +0200 <tomsmeding> if it isn't, file a bug :p
2025-09-07 11:47:42 +0200 <arahael> Excellent.
2025-09-07 11:47:40 +0200 <tomsmeding> yes
2025-09-07 11:47:35 +0200 <arahael> Ah, so if it were to block the OS thread, it should be very very strongly called out in the documentation, then?
2025-09-07 11:47:33 +0200 <tomsmeding> "unsafe" foreign calls, that is
2025-09-07 11:47:25 +0200 <tomsmeding> there are exceptions: foreign calls block
2025-09-07 11:47:14 +0200 <tomsmeding> arahael: in principle, _nothing_ in the GHC RTS blocks the OS thread
2025-09-07 11:46:59 +0200 <tomsmeding> if you don't need to handle the messages centrally in one place you can handle them in the A and B threads immediately, of course
2025-09-07 11:46:57 +0200 <arahael> Awesome, that works then, how would I normally know, though, just from reading the code? I'm observing functions such as: threadWaitReadPty :: Pty -> IO ()
2025-09-07 11:46:39 +0200 <tomsmeding> start two forkIO threads to wait for data on A and B, and send the results on a Chan (Either MsgA MsgB) that you consume in a third forkIO thread