Skip Menu |

This queue is for tickets about the Future-AsyncAwait CPAN distribution.

Report information
The Basics
Id: 130683
Status: open
Priority: 0/
Queue: Future-AsyncAwait

People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.33
Fixed in: (no value)



Subject: await can sometimes corrupt @_
Given the function: async sub read_reg { my $self = shift; my $reg = shift; print STDERR "ENTER BNO055 read_reg snail=<@_>\n"; ... some code here involving await print STDERR " now snail=<@_>\n"; ... } Sometimes this runs fine, but sometimes the value of @_ gets corrupted: ENTER BNO055 read_reg snail=<8 forcecache> now snail=<8 forcecache> (correct) ENTER BNO055 read_reg snail=<4 forcecache> now snail=<Future=HASH(0x555556458bd0)> (wrong) I don't have an exact minimal test case yet as the real code involves layers of Device::Chip + Device::BusPirate + Future::IO, but a difference appears to be whether the inner code invoked by the await itself uses F-AA -- Paul Evans
For now an easy workaround is just not to use `@_` and instead unpack it as my @args = @_; but it would be nice to get to the bottom of this one sometime -- Paul Evans
With the lack of refcounting on @_ entries, I don't see how access to @_ after an await boundary would be reliable anyway. As an example: my $f = Future->new; my $x = do { my $temp = 123; (async sub { # Suspend here await $f; # On resume, $temp is very likely to have dropped out of scope, # so the original @_ slot isn't going to be useful anyway print $_[0] })->($temp) }; $f->done; I'd suggest just documenting it as a known limitation due to Perl's internal architecture. Trying to restore @_ slots seems like a recipe for more "bizarre copy of array" and similar errors.