[00:20] Any reason I can't submit a bug report at https://github.com/raku-community-modules/NativeHelpers-Blob/issues ? [00:35] try again? [00:36] timo: Thanks! :) [01:46] *** wayland left [01:46] *** wayland joined [01:49] *** hulk joined [01:50] *** kylese left [02:10] *** rmv left [02:15] *** hulk left [02:15] *** kylese joined [02:18] timo: I will update my rakudo to 2026.06 and pray it helps with the freeze 🙏 [02:26] hmmm: MoarVM panic: Heap corruption detected: pointer 0x4e2f2399868 to past fromspace [02:39] (thats when trying to run rbt: $ ./bin/rbt -o ./tmp ./resources/debian.torrent) [02:46] created an issue: https://github.com/rakudo/rakudo/issues/6368 [02:51] after retrying it seems to freeze instantly now xD no heap corruption after restarting the program but it doesnt do anything [03:02] *** lichtkind__ joined [03:05] *** lichtkind_ left [04:01] *** lichtkind_ joined [04:04] *** lichtkind__ left [04:17] ¦ docker: 606999aa18 | AntonOks++ | 6 files [04:17] ¦ docker: Bump to 2026.06 [skip workflow] [04:17] ¦ docker: review: https://github.com/rakudo/docker/commit/606999aa18 [04:33] the heap corruption error is most commonly caused by using non-thread-safe datastructures concurrently. the freeze is probably the bug with utf8 decoding with errors [04:58] *** hurufu joined [05:09] but it can also be a bug inside moarvm where the temporary roots aren't being managed correctly, or a gc_mark function isn't correct [05:35] *** rmv joined [05:37] it could be that it's caused by writing to socket without await [05:40] *** rmv left [05:43] that would surprise me [05:45] I'm not sure if asyncwritebytes is safe as fire-and-forget [05:46] all async things go through the single async io thread [05:46] I see, so it's impossible pretty much [05:47] Okay then, maybe it's the use of supply fater all – recently I found out that supply is not single-threaded in a way I thought at all [05:48] it only happens to look single-threaded through the single block being synchronized with Lock::Async [05:49] m: sub foo($n) { supply { whenever Supply.interval(.1).head(3) { "$n: $_".say; sleep 1; } } }; react { for ^3 -> $n { whenever foo($n) { LAST { say "end" } } } } [05:49] rakudo-moar 1b77a9023: OUTPUT: «0: 0␤1: 0␤2: 0␤0: 1␤1: 1␤2: 1␤0: 2␤1: 2␤2: 2␤end␤end␤end␤» [05:49] it is reasonable, but it also means that sub-supplies are fully concurrent [05:51] meaning that rbt uses `BT::PiecesManager $.pieces-manager;` concurrently [05:52] supply doesn't introduce multithreading on its own, and no single supply or react block can have multiple threads running code inside of it at the same time [05:52] but of course you can instantiate the same react block or supply block multiple times [05:53] indeed, and that's what happens here [05:53] > https://github.com/4zv4l/rbt/blob/main/lib/BT/Downloader.rakumod#L35 [05:54] how so? [05:55] i didn't dig as far into the code [05:55] every peer starts its own supply that connects, receives data and processes chunks [05:56] that by itself shouldn't yet introduce concurrency [05:57] but if a peer doesn't find a chunk to fetch, it re-queues itself onto the scheduler [05:57] by using `whenever Promise.in(2) { $!work-bus.emit(True) }` [05:59] that lands in the same supply block again, so it would still be locking out concurrent processing of the peer itself, right? but that's not enough? [05:59] Yeah, it's okay to do that, peer doesn't do any work concurrently, however [06:00] it gets outside state [06:01] ah, now i see where the PiecesManager is being used [06:01] *** guifa left [06:01] so multiple peers start touching shared concurrently with no locks [06:01] that looks suspicious, yeah [06:05] *** hurufu left [06:07] *** ab5tract left [06:09] *** leont left [06:10] *** ab5tract joined [06:11] oh, also, IO::Socket::Async.connect immediately converts supply into multi-threaded [06:12] m: sub foo($n) { supply { whenever ^1 { whenever ^3 { "$n: $_".say; sleep .01; } } } }; react { for ^3 -> $n { whenever foo($n) { LAST { say "end" } } } } # sane, single-threaded [06:12] rakudo-moar 1b77a9023: OUTPUT: «0: 0␤0: 1␤0: 2␤1: 0␤1: 1␤1: 2␤2: 0␤2: 1␤2: 2␤end␤end␤end␤» [06:12] *** leont joined [06:13] m: sub foo($n) { supply { whenever IO::Socket::Async.connect("1.1.1.1", "80") { .close; whenever ^3 { "$n: $_".say; sleep .2; } } } }; react { for ^3 -> $n { whenever foo($n) { LAST { say "end" } } } } # suddenly multithreaded [06:13] rakudo-moar 1b77a9023: OUTPUT: «A react block:␤ in block at line 1␤␤Died because of the exception:␤ Failed to resolve host name '1.1.1.1' with family 0.␤ Error: Address family for hostname not supported␤ in block at line 1␤␤» [06:13] m: sub foo($n) { supply { whenever Promise.in(.1) { .close; whenever ^3 { "$n: $_".say; sleep .2; } } } }; react { for ^3 -> $n { whenever foo($n) { LAST { say "end" } } } } # same, but without .connect [06:13] rakudo-moar 1b77a9023: OUTPUT: «A react block:␤ in block at line 1␤␤Died because of the exception:␤ No such method 'close' for invocant of type 'Bool'. Did you mean any of␤ these: 'clone', 'cos', 'cosec', 'cosh'?␤ in block at line 1␤␤» [06:13] m: sub foo($n) { supply { whenever Promise.in(.1) { whenever ^3 { "$n: $_".say; sleep .2; } } } }; react { for ^3 -> $n { whenever foo($n) { LAST { say "end" } } } } # same, but without .connect [06:13] rakudo-moar 1b77a9023: OUTPUT: «0: 0␤1: 0␤2: 0␤0: 1␤1: 1␤2: 1␤0: 2␤1: 2␤2: 2␤end␤end␤end␤» [06:15] it's very easy to promote the supply onto the scheduler [06:38] *** Sgeo left [07:11] so my assumption that as long as I dont use a start{} and that then only 1 whenever block can run at a time isnt right.. ? ;-; [07:21] no, but your assumption that supply is single-threaded is right [07:22] so instead of calling methods you can simply send "processing requests" over supplier [07:26] or over channel [07:26] that would contain kept or broken promise [07:38] or use Lock::Async for BT::PiecesManager [07:38] or use OO::Actors [07:39] plenty of possibilities [07:49] *** dustinm` left [07:49] *** dakkar joined [08:08] *** dustinm` joined [08:12] I am not amazing in async programming but, the 2 only shared resources in this client are: the pieces to download (use a channel so its fine right?) and the piece-manager, but it also should be fine, the OS should handle the writing to file pretty well no ? and they write to different part of the file anyway so shouldnt corrupt it [08:15] *** abraxxa joined [08:15] the piece using channels is probably right, because it's hard to get it wrong [08:15] the piece using simple method calls is probably wrong, because it's easy to get it wrong ;P [08:23] *** abraxxa left [08:24] *** abraxxa joined [08:29] *** xinming joined [08:54] /0\ [08:54] brain boom [09:06] I'm relatively simple when it comes to concurrency - if's mutable, concurrently accessed and has no locks it's buggy, I usually don't even read the code, just wrap everything in lock.protect [09:07] btw, have you seen the thingie I made for supplies the other day? https://glot.io/snippets/hjzcs17o93 [09:07] you just add `INSPECT-SUPPLY;` at the top of the supply block and magically get flood of info [09:17] uh `:value($_),` that was actually not planned [09:17] so this is fixed (and uses my earlier example) https://glot.io/snippets/hk0jgyybsw [09:51] *** dakkar left [09:51] *** dakkar joined [09:59] *** rjbs left [10:00] *** rjbs joined [10:31] I’ll add locks to the piece manager o7, and I’ll check your supply inspector 🔥 thank you! 🙏 [10:35] *** dakkar left [10:37] *** wayland left [10:43] *** rmv joined [10:46] *** wayland76 joined [11:04] alright I added a lock in main and testing, and added the INSPECT-SUPPLY in the testing branch [11:04] I still get the memory issue with the new raku version, I will try to downgrade and test the testing branch xD [12:50] *** rmv left [13:10] *** rmv joined [13:10] *** rmv left [13:10] *** rmv joined [13:15] *** rmv left [13:28] *** rmv joined [13:33] *** rmv left [13:50] *** rmv joined [13:50] *** rmv left [13:50] *** rmv joined [13:50] *** hurufu joined [13:59] *** rmv left [14:12] *** rmv joined [14:44] apparently torrent client is a good benchmark of every single thing in networking and concurrency :) [15:51] *** human-blip left [15:53] *** human-blip joined [16:08] *** vrurg_ joined [16:09] *** vrurg left [16:31] *** vrurg joined [16:35] *** vrurg_ left [16:52] *** abraxxa left [18:34] *** sjn left [18:35] *** Sgeo joined [18:39] *** sjn joined [19:34] *** guifa joined [19:41] *** hurufu left [20:25] *** wayland joined [20:25] *** wayland76 left