| RT#132042 |
[BUG]
[CONC]
[TESTNEEDED]
Concurrently calling `say` can cause Rakudo to hang
|
| RT#131871 |
[CONC]
[REGEX]
[REGEX]
Regex code block closing over lexical variable, is not threadsafe
|
| RT#131870 |
[CONC]
[REGEX]
Capture lookup inside regex is not threadsafe
|
| RT#130796 |
[CONC]
Data races somewhere in SEQUENCE and/or continuation resuming code
|
| RT#130716 |
[CONC]
unbounded supply {} + react {} = pseudo-hang
|
| RT#130690 |
[BUG]
[BUG]
[CONC]
attribute from one role used in another via private method gone missing
|
| RT#130576 |
[CONC]
.race & .hyper break [+] (1..100)
|
| RT#130494 |
[BUG]
[CONC]
[PERF]
Using Proc::Async with tap leads to memory leak
|
| RT#130370 |
[CONC]
Tapping on a very active .out of Proc::Async wrecks the work queue
|
| RT#130342 |
[CONC]
supply tap: No such method 'phasers' for invocant of type 'Code'
|
| RT#130107 |
[CONC]
[TESTNEEDED]
unkown system error 0 via Proc::Async
|
| RT#130042 |
[CONC]
t/04-nativecall/20-concurrent.t flops
|
| RT#129882 |
[CONC]
[IO]
[TESTNEEDED]
[TESTNEEDED]
Proc with `.in.close` and `.out.slurp-rest` in different threads, hangs
|
| RT#129845 |
[CONC]
[TESTNEEDED]
[TESTNEEDED]
`.dir` returns corrupted `IO::Path`s under concurrent load
|
| RT#129787 |
[CONC]
die/CATCH inside a start-block with a channel heisenbugs
|
| RT#129263 |
[CONC]
Outer dynamic variable not found in nested `start` block
|
| RT#129234 |
[BUG]
[CONC]
`.hyper` and `.race` resume after exceptions
|
| RT#128896 |
[CONC]
Punning a role in a different thread a bit fragile
|
| RT#128878 |
[CONC]
Supply.interval is drifting
|
| RT#128718 |
[CONC]
Strange error when attempting to redo a supply block
|
| RT#128084 |
[BUG]
[BUG]
[CONC]
`.hyper/.race.map(&f)` produces an empty sequence if `&f` is a multi-sub
|
| RT#127987 |
[CONC]
Block.assuming method apparently not reentrant
|
| RT#127974 |
[BUG]
[CONC]
sprintf() not threadsafe/reentrant if the format tokens use explicit indices
|
| RT#127659 |
[CONC]
Possible race in Supply simple operations when closing Tap
|
| RT#127452 |
[BUG]
[CONC]
hyper is very broken, *sometimes* it returns nothing
|
| RT#127208 |
[CONC]
[SEGV]
[TESTCOMMITTED]
Non-deterministic segfaults in parallel code
|
| RT#126787 |
[CONC]
Promises that are not awaited or .then'd will swallow exceptions.
|
| RT#126597 |
[BUG]
[BUG]
[CONC]
.race.grep(...) and .hyper.grep(...) produce an empty sequence
|
| RT#126425 |
[CONC]
Proc::Async methods can have unpredictable and nondeterministic order
|
| RT#126381 |
[CONC]
Proc::Async has no way to get to a child's PID
|
| RT#126277 |
[CONC]
[OSX]
IO::Socket::Async + `run` exits unexpectedly on [OSX]
|
| RT#126169 |
[CONC]
t/spec/S17-supply/watch-path.t fails occasionally under high load.
|
| RT#125978 |
[BUG]
[CONC]
[SEGV]
(and other crashes) when using .hyper
|
| RT#125656 |
[CONC]
Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()
|
| RT#125655 |
[CONC]
Garbage collected running Proc::Async objects don't seem to clean up their handles, causing libuv to abort()
|
| RT#125654 |
[CONC]
Killing a Proc::Async doesn't seem to clean up its file descriptors, causing an abort() from libuv
|
| RT#125653 |
[CONC]
[TESTNEEDED]
A promise returned by Proc::Async.start will never be kept or broken if the process is killed by the current process
|
| RT#125516 |
[CONC]
[OSX]
"Use of Nil in numeric context" warning seen with Proc::Async exitcode on [OSX] only
|
| RT#125048 |
[CONC]
:./S17-procasync/print.t line:50 reason: Flapping tests
|
| RT#125047 |
[CONC]
S17-procasync/basic.t line:80 reason: 'returns Nil (flapping tests)'
|
| RT#124827 |
[CONC]
S17-supply/delayed.t line:27 reason: doesn't work or can't test
|
| RT#124826 |
[CONC]
S17-supply/delayed.t line:14 reason: doesn't work or can't test
|
| RT#124823 |
[CONC]
S17-supply/rotor.t line:10 reason: 'only deprecated so far'
|
| RT#124822 |
[CONC]
S17-supply/stable.t line:14 reason: doesn't work or can't test
|
| RT#124774 |
[CONC]
S17-scheduler/basic.t line:16 reason: waiting for new '.loads' semantics
|
| RT#124074 |
[CONC]
Closing a Channel on which a worker is receiving may or may not trigger a X::Channel::ReceiveOnDone exception
|
| RT#123667 |
[CONC]
Attempt to parallelize existing program leads to type check failure, with find_method_fallback in the backtrace
|
| RT#123461 |
[CONC]
Channel.send prone to race conditions
|
| RT#122790 |
[CONC]
Tapping multiple signals fails strangely
|
| RT#122709 |
[BUG]
[BUG]
[CONC]
`await`ing a Promise in a different thread sometimes hangs
|