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 +0200 | merijn | (~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 +0200 | trickard_ | 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 +0200 | segfaultfizzbuzz | (~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 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-07 11:53:25 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2025-09-07 11:52:08 +0200 | <arahael> | Ah, cool. |
2025-09-07 11:51:59 +0200 | segfaultfizzbuzz | (~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 |