wayland Any reason I can't submit a bug report at github.com/raku-community-modules/...lob/issues ? 00:20
timo try again? 00:35
wayland timo: Thanks! :) 00:36
01:46 wayland left, wayland joined 01:49 hulk joined 01:50 kylese left 02:10 rmv left 02:15 hulk left, kylese joined
simon_sibl timo: I will update my rakudo to 2026.06 and pray it helps with the freeze 🙏 02:18
hmmm: MoarVM panic: Heap corruption detected: pointer 0x4e2f2399868 to past fromspace 02:26
(thats when trying to run rbt: $ ./bin/rbt -o ./tmp ./resources/debian.torrent) 02:39
created an issue: github.com/rakudo/rakudo/issues/6368 02:46
after retrying it seems to freeze instantly now xD no heap corruption after restarting the program but it doesnt do anything 02:51
03:02 lichtkind__ joined 03:05 lichtkind_ left 04:01 lichtkind_ joined 04:04 lichtkind__ left
Geth docker: 606999aa18 | AntonOks++ | 6 files
Bump to 2026.06 [skip workflow]
 04:17
timo 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:33
04:58 hurufu joined
timo 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:09
05:35 rmv joined
Voldenet it could be that it's caused by writing to socket without await 05:37
05:40 rmv left
timo that would surprise me 05:43
Voldenet I'm not sure if asyncwritebytes is safe as fire-and-forget 05:45
timo all async things go through the single async io thread 05:46
Voldenet I see, so it's impossible pretty much
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:47
it only happens to look single-threaded through the single block being synchronized with Lock::Async 05:48
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
camelia 0: 0
1: 0
2: 0
0: 1
1: 1
2: 1
0: 2
1: 2
2: 2
end
end
end
Voldenet it is reasonable, but it also means that sub-supplies are fully concurrent
meaning that rbt uses `BT::PiecesManager $.pieces-manager;` concurrently 05:51
timo 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
Voldenet indeed, and that's what happens here 05:53
> github.com/4zv4l/rbt/blob/main/lib...akumod#L35
timo how so? 05:54
i didn't dig as far into the code 05:55
Voldenet every peer starts its own supply that connects, receives data and processes chunks
timo that by itself shouldn't yet introduce concurrency 05:56
Voldenet 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) }`
timo 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
Voldenet Yeah, it's okay to do that, peer doesn't do any work concurrently, however
it gets outside state 06:00
timo ah, now i see where the PiecesManager is being used 06:01
06:01 guifa left
Voldenet so multiple peers start touching shared concurrently with no locks 06:01
timo that looks suspicious, yeah
06:05 hurufu left 06:07 ab5tract left 06:09 leont left 06:10 ab5tract joined
Voldenet oh, also, IO::Socket::Async.connect immediately converts supply into multi-threaded 06:11
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
camelia 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
Voldenet 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
camelia A react block:
in block <unit> at <tmp> 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 <unit> at <tmp> line 1
Voldenet 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
camelia A react block:
in block <unit> at <tmp> 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 <tmp> line 1
Voldenet 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
camelia 0: 0
1: 0
2: 0
0: 1
1: 1
2: 1
0: 2
1: 2
2: 2
end
end
end
Voldenet it's very easy to promote the supply onto the scheduler 06:15
06:38 Sgeo left
simon_sibl 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:11
Voldenet no, but your assumption that supply is single-threaded is right 07:21
so instead of calling methods you can simply send "processing requests" over supplier 07:22
or over channel 07:26
that would contain kept or broken promise
or use Lock::Async for BT::PiecesManager 07:38
or use OO::Actors
plenty of possibilities 07:39
07:49 dustinm` left, dakkar joined 08:08 dustinm` joined
simon_sibl 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:12
08:15 abraxxa joined
Voldenet 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
simon_sibl /0\ 08:54
brain boom
Voldenet 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:06
btw, have you seen the thingie I made for supplies the other day? glot.io/snippets/hjzcs17o93 09:07
you just add `INSPECT-SUPPLY;` at the top of the supply block and magically get flood of info
uh `:value($_),` that was actually not planned 09:17
so this is fixed (and uses my earlier example) glot.io/snippets/hk0jgyybsw
09:51 dakkar left, dakkar joined 09:59 rjbs left 10:00 rjbs joined
simon_sibl I’ll add locks to the piece manager o7, and I’ll check your supply inspector 🔥 thank you! 🙏 10:31
10:35 dakkar left 10:37 wayland left 10:43 rmv joined 10:46 wayland76 joined
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, rmv left, rmv joined 13:15 rmv left 13:28 rmv joined 13:33 rmv left 13:50 rmv joined, rmv left, rmv joined, hurufu joined 13:59 rmv left 14:12 rmv joined
Voldenet apparently torrent client is a good benchmark of every single thing in networking and concurrency :) 14:44
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, wayland76 left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!