2025/01/31

Newest at the top

2025-01-31 22:02:02 +0100 <dminuoso> euouae: Like I said, the machinery was not build for loop detection but for preventing concurrent evaluation of the same thunk between two haskell threads.
2025-01-31 22:01:53 +0100kimiamania8(~65804703@user/kimiamania) kimiamania
2025-01-31 22:01:35 +0100 <mauke> only in this case it's more like "if you encounter yourself on the road, kill the current thread"
2025-01-31 22:01:29 +0100kimiamania8(~65804703@user/kimiamania) (Quit: PegeLinux)
2025-01-31 22:01:18 +0100 <dminuoso> But dont ever rely on it firing.
2025-01-31 22:01:16 +0100 <mauke> if you encounter the buddha on the road, kill him
2025-01-31 22:01:09 +0100 <dminuoso> If it triggers, there's definitely an infinite loop and you can celebrate. :)
2025-01-31 22:00:43 +0100 <euouae> well eah, that's good, heuristics can misfire
2025-01-31 22:00:09 +0100 <dminuoso> Its not even a heuristic.
2025-01-31 22:00:08 +0100 <euouae> right
2025-01-31 22:00:00 +0100 <dminuoso> euouae: Like I said: It can only detect a particular kind of infinite loop.
2025-01-31 21:59:23 +0100 <euouae> so maybe it's not reliable, just a heuristic?
2025-01-31 21:59:14 +0100 <euouae> yeah I was thinking that <<loop>> detection seems roughly like the halting prolbem
2025-01-31 21:58:17 +0100 <dminuoso> See https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-objects#black-holes for some details on blackhole
2025-01-31 21:58:16 +0100sarna(~sarna@d224-221.icpnet.pl) sarna
2025-01-31 21:57:48 +0100 <dminuoso> euouae: Note, that every object has a pointer to an info table, and that info table contains entry code. Evaluation is driven by just jumping into that entry code
2025-01-31 21:57:29 +0100sarna(~sarna@d224-221.icpnet.pl) (Ping timeout: 260 seconds)
2025-01-31 21:56:29 +0100 <dminuoso> euouae: Start with the `Heap Objects` section
2025-01-31 21:56:11 +0100 <dminuoso> Is a good website to remember.
2025-01-31 21:56:05 +0100 <dminuoso> euouae: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-objects
2025-01-31 21:53:53 +0100 <ash3en> i mean the haskell library: https://hackage.haskell.org/package/jack-0.7.2.2/docs/Sound-JACK-MIDI.html
2025-01-31 21:53:39 +0100 <ash3en> using jack midi with haskell: do i have to manage memory or something?
2025-01-31 21:53:08 +0100 <dminuoso> It was recognized we could use the same machinery to detect some forms of infinite loops
2025-01-31 21:52:42 +0100 <dminuoso> mauke: Yes. Its really just a kind of mutual exclusion lock for thunks.
2025-01-31 21:52:24 +0100 <dminuoso> You can think of it as some kind of mutual exclusion lock, but with special logic to detect if the entry code recursed into itself.
2025-01-31 21:51:58 +0100 <euouae> oh mauke's example relates to black holes? I'll read the whole convo then
2025-01-31 21:51:48 +0100 <dminuoso> If not, it will set that mark.
2025-01-31 21:51:39 +0100 <dminuoso> Now that entry code both checks for a particular mark BLACKHOLE to be set, if its set, you get a <<loop>> assuming this happened from within the same haskell thread.
2025-01-31 21:51:15 +0100 <euouae> interestingly `let x = head [x] in x` just hangs in ghci
2025-01-31 21:50:41 +0100 <dminuoso> euouae: and you demand that value by just jmp'ing into that memory region.
2025-01-31 21:50:25 +0100 <dminuoso> euouae: So roughly, if you have `let x = <expensive> in ..` then we can think of x being represented in memory as some memory region with a bunch of code
2025-01-31 21:49:53 +0100 <euouae> sorry I'm reading from the top so I'm trying to catch up on what was said
2025-01-31 21:49:44 +0100 <euouae> mauke, is <<loop>> possible because of sharing?
2025-01-31 21:49:12 +0100 <dminuoso> Even in single threaded RTS you will have concurrency.
2025-01-31 21:49:09 +0100 <mauke> ah, right
2025-01-31 21:48:34 +0100 <dminuoso> While the other use of threads if about haskell threads.
2025-01-31 21:48:24 +0100 <dminuoso> Note that "threaded RTS" talks about OS threads
2025-01-31 21:48:08 +0100 <dminuoso> mauke: Im not sure how the threaded RTS changes, but blackholing should be needed for single threaded RTS too.
2025-01-31 21:46:05 +0100 <dminuoso> So consider it a bonus *if* it triggers.
2025-01-31 21:46:00 +0100 <mauke> i.e. in multi-thread mode a thread could re-enter the thunk and end up waiting for itself (deadlock)
2025-01-31 21:45:54 +0100 <dminuoso> (And it does not work reliably either for a bunch of reasons)
2025-01-31 21:45:44 +0100dsrt^(~dsrt@108.192.66.114) (Ping timeout: 252 seconds)
2025-01-31 21:45:23 +0100 <dminuoso> The <<loop>> is just some opportunistic debugging helper, its not the core feature.
2025-01-31 21:45:18 +0100 <mauke> did they change that? I have a vague memory that <<loop>> detection didn't work in multi-thread mode
2025-01-31 21:45:04 +0100 <dminuoso> So it gets woken up whenever the thunk finished.
2025-01-31 21:44:48 +0100 <dminuoso> If another thread enters a blackhole, it gets put on a list to be woken up later.
2025-01-31 21:44:33 +0100 <dminuoso> mauke: If the same thread enters a blackhole, that blackhole acts as loop detection.,
2025-01-31 21:44:25 +0100 <dminuoso> mauke: Okay, so there's two behaviors to blackhole.
2025-01-31 21:44:08 +0100alexherbo2(~alexherbo@2a02-8440-3503-94e0-1866-04f2-f81a-c1ec.rev.sfr.net) (Remote host closed the connection)
2025-01-31 21:44:07 +0100 <mauke> so if another thread tries to evaluate the same thunk later, it will simply wait until the first thread is done computing a value