Fixed with be9e19efd97755cfd , tests needed!
> On 10 Nov 2017, at 03:28, David Lowe wrote:
>
> This crash still occurs with rakudo 2017.10.
>
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT
> wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation o
Fixed with be9e19efd97755cfd , tests needed!
> On 10 Nov 2017, at 03:28, David Lowe wrote:
>
> This crash still occurs with rakudo 2017.10.
>
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT
> wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation o
Ah, indeed, so a workaround would be:
my $lock = Lock.new;
my $set = SetHash.new;
await ^16 .map: {
start {
for ^1 {
$lock.protect: { $set<1> = True; 1 }
$lock.protect: { $set<1> = False; 1 }
}
}
}
So maybe a solution would be to test for Proxy of the retu
Ah, indeed, so a workaround would be:
my $lock = Lock.new;
my $set = SetHash.new;
await ^16 .map: {
start {
for ^1 {
$lock.protect: { $set<1> = True; 1 }
$lock.protect: { $set<1> = False; 1 }
}
}
}
So maybe a solution would be to test for Proxy of the retu
I already figured out that it's about sinking the result of assigning to
the SetHash. When you access it you get a proxy, that is the return
value of the lock-protected block, and the proxy gets sunk outside of
it, thus causing concurrent access to the SetHash.
On 14/11/17 16:03, Elizabeth Mattij
I already figured out that it's about sinking the result of assigning to
the SetHash. When you access it you get a proxy, that is the return
value of the lock-protected block, and the proxy gets sunk outside of
it, thus causing concurrent access to the SetHash.
On 14/11/17 16:03, Elizabeth Mattij
reducing the code to:
use nqp;
my $lock = Lock.new;
my $hash := nqp::hash;
await ^16 .map: {
start {
for ^1000 {
$lock.protect: { nqp::bindkey($hash,"a",1) }
$lock.protect: { nqp::deletekey($hash,"a") }
}
}
}
does *not* make it crash. So it would appear that i
reducing the code to:
use nqp;
my $lock = Lock.new;
my $hash := nqp::hash;
await ^16 .map: {
start {
for ^1000 {
$lock.protect: { nqp::bindkey($hash,"a",1) }
$lock.protect: { nqp::deletekey($hash,"a") }
}
}
}
does *not* make it crash. So it would appear that i
This does not seem to appear if you add at least one key to the set before the
await. The segfault only appears to occur when adding a first or removing the
last key from the SetHash.
> On 10 Nov 2017, at 03:28, David Lowe wrote:
>
> This crash still occurs with rakudo 2017.10.
>
> On Thu, O
This does not seem to appear if you add at least one key to the set before the
await. The segfault only appears to occur when adding a first or removing the
last key from the SetHash.
> On 10 Nov 2017, at 03:28, David Lowe wrote:
>
> This crash still occurs with rakudo 2017.10.
>
> On Thu, O
This crash still occurs with rakudo 2017.10.
On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT
wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> a sum
This crash still occurs with rakudo 2017.10.
On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT
wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> a sum
12 matches
Mail list logo
