From liukan@360.cn

https://gist.github.com/anonymous/79a7e59cf3160f6ac09e

07​:31 kanl repeating a previous question, is it by design or a bug that Proc​::Async stdout does not tap output in its entirety? ( i thought it's neither )
07​:32 moritz kanl​: sounds like a bug
07​:32 masak kanl​: please submit an issue on the project with pertinent details

- kan

From @skids

I also ran into this behavior trying to use Proc​::Async's Supplies.

Some of it hinges on whether all tap code should be complete before a done
callback is invoked -- it would seem intuitive, but making that happen would
prevent long-running taps from being useful (though they could start { }
something instead). Probably one should expect/be warned that taps may even
run in parallel and not rely on their order even with respect to the
:done callback.

However, Supply.Channel should probably be made smart enough to make a
supply serially coherent (perhaps optionally, but definitely with
respect to :done), and does not seem to​:

https://gist.github.com/skids/e8149189ac5c24ae493e

...and one way to do so would be to ensure that "whenever" blocks get entered
in the expected order (maybe they do already) and implement Supply.Channel
using those constructs, though my attempts to do it on a one-liner are not
being very fruitful right now.

The RT System itself - Status changed from 'new' to 'open'

From @skids

...and one way to do so would be to ensure that "whenever" blocks get
entered
in the expected order (maybe they do already) and implement
Supply.Channel
using those constructs

This turned out to be more stable, but not perfect -- when it does not die
at 8 reps it goes for 1k to 3k reps before something goes amiss​:

$ perl6 -e 'sub f { my $cmd = Proc​::Async.new(​:path<ls>); my $c = Channel.new; (supply { whenever $cmd.stdout -> $l { $c.send($l); }; $cmd.start }).Promise.then({$c.close}); $c.join }; my $f = f(); die "first rep" unless $f.?chars; loop { my $h = f(); state $i = 0; $i++; die "$i reps" unless $f.chars == $h.?chars }'

From @jnthn

On Tue Jun 30 01​:02​:15 2015, liukan@​360.cn wrote​:

https://gist.github.com/anonymous/79a7e59cf3160f6ac09e

07​:31 kanl repeating a previous question, is it by design or a
bug that Proc​::Async stdout does not tap output in its entirety? ( i
thought it's neither )
07​:32 moritz kanl​: sounds like a bug
07​:32 masak kanl​: please submit an issue on the project with
pertinent details

Yes, there was a bug that could cause data loss. Fixed now, and a test is in S17-procasync/stress.t.

@jnthn - Status changed from 'open' to 'resolved'