Newest at the top
2025-03-22 22:21:34 +0100 | <EvanR> | oof that edit caused a blast from the past |
2025-03-22 22:21:03 +0100 | <haskellbridge> | <dmjio> I have some nested threads each with its own stack and heap, the threads are bubbling up killThread events. While bubbling I’m trying to invoke a yield so their stacks can get evaluated and these thunks on the heap will get forced before they all get GC’d. What’s happening is that these thunks are never getting forced and just getting GC’d before evaluation. When I do a "threadDelay 0" they do get evaluated |
2025-03-22 22:20:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-03-22 22:15:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-22 22:12:53 +0100 | <haskellbridge> | <dmjio> I’ll test on threaded GHC to see if yield behaves |
2025-03-22 22:11:45 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
2025-03-22 22:11:45 +0100 | dibblego | (~dibblego@116-255-1-119.ip4.superloop.au) (Changing host) |
2025-03-22 22:11:45 +0100 | dibblego | (~dibblego@116-255-1-119.ip4.superloop.au) |
2025-03-22 22:07:03 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 252 seconds) |
2025-03-22 22:05:09 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
2025-03-22 22:04:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-03-22 22:04:39 +0100 | <haskellbridge> | <dmjio> Yield could mean give me a different set of threads, not a different set of stack frames. It depends what it means. I bet the yield is defined only in terms of multicore |
2025-03-22 22:02:07 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
2025-03-22 22:02:07 +0100 | dibblego | (~dibblego@116-255-1-119.ip4.superloop.au) (Changing host) |
2025-03-22 22:02:07 +0100 | dibblego | (~dibblego@116-255-1-119.ip4.superloop.au) |
2025-03-22 22:00:31 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-03-22 22:00:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-22 21:55:14 +0100 | hattckory | (~hattckory@70.27.118.207) (Ping timeout: 260 seconds) |
2025-03-22 21:51:52 +0100 | <haskellbridge> | <dmjio> I have some nested threads each with its own stack and heap, the threads are bubbling up killThread events. While bubbling I’m trying to invoke a yield so their stacks can get evaluated and these thunks on the heap will get forced before they all get GC’d. What’s happening is that these thunks are never getting forced and just getting GC’d before evaluation. When I do a thread delay 0 they do get evaluated |
2025-03-22 21:50:08 +0100 | <haskellbridge> | <dmjio> It’s an L:m:n model yea |
2025-03-22 21:50:00 +0100 | stackdroid18 | (14094@de1.hashbang.sh) (Client Quit) |
2025-03-22 21:49:47 +0100 | <EvanR> | you can have more capabilities than cores |
2025-03-22 21:49:47 +0100 | <haskellbridge> | <dmjio> Threads |
2025-03-22 21:49:43 +0100 | <haskellbridge> | <dmjio> The are heap objects |
2025-03-22 21:49:37 +0100 | <EvanR> | not cores |
2025-03-22 21:49:32 +0100 | <EvanR> | I only know about "capabilities" |
2025-03-22 21:49:30 +0100 | <haskellbridge> | <dmjio> Cores and threads are very different |
2025-03-22 21:49:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-03-22 21:49:19 +0100 | <haskellbridge> | <dmjio> And when all you have is a single core it might not make a new schedule |
2025-03-22 21:49:17 +0100 | <EvanR> | is "core switch" new jargon |
2025-03-22 21:48:46 +0100 | <haskellbridge> | <dmjio> It looks like it’s just doing a core switch |
2025-03-22 21:48:09 +0100 | <EvanR> | as opposed to being a no op |
2025-03-22 21:48:04 +0100 | <EvanR> | like the entire point of yield |
2025-03-22 21:47:57 +0100 | <EvanR> | isn't yield how you switch threads in non -threaded |
2025-03-22 21:47:56 +0100 | stackdroid18 | (14094@de1.hashbang.sh) |
2025-03-22 21:44:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-22 21:43:07 +0100 | <haskellbridge> | <dmjio> I bet as an optimization single core doesn’t make a new schedule |
2025-03-22 21:42:33 +0100 | stackdroid18 | (14094@user/stackdroid) (Client Quit) |
2025-03-22 21:39:33 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
2025-03-22 21:39:11 +0100 | stackdroid18 | (14094@user/stackdroid) stackdroid |
2025-03-22 21:38:53 +0100 | stackdroid18 | (14094@user/stackdroid) (Client Quit) |
2025-03-22 21:37:58 +0100 | <haskellbridge> | <dmjio> Yield could try to invoke a core switch and then no op if it sees a single core. Whereas a delay is making a new schedule |
2025-03-22 21:37:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-03-22 21:36:47 +0100 | <haskellbridge> | <dmjio> That’s not what I’m seeing. When I threadDelay 0 it does invoke the scheduler, pushes current thread to back queue; evals other stacks, comes back to mine last. Yield on single core isn’t doing that for me. |
2025-03-22 21:36:45 +0100 | stackdroid18 | (14094@user/stackdroid) stackdroid |
2025-03-22 21:34:06 +0100 | <monochrom> | No, because green threads still exist. |
2025-03-22 21:32:05 +0100 | <haskellbridge> | <dmjio> Is "yield" a no-op on single core (no "-threaded") GHC |
2025-03-22 21:30:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-22 21:27:19 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f4018176379d3bca4ca.dip0.t-ipconnect.de) acidjnk |
2025-03-22 21:19:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |