select() in this context is arguably a workaround for lack of threads, although it can also be used to simulate threading ("green threads").
On Thu, Jul 27, 2017 at 8:41 PM, David Warring <david.warr...@gmail.com> wrote: > Perl 5 and C have the select call that lets you determine which of a group > of file-descriptor are ready for reading and writing. I thought it might be > useful here. > > https://en.wikipedia.org/wiki/Select_(Unix) > > I've found a module by Tadzik, https://github.com/tadzik/IO-Select, but > it's looking defunct and Parrot specifc. > > Are we missing a working 'select' call? > - David > > On Fri, Jul 28, 2017 at 12:04 PM, Brandon Allbery <allber...@gmail.com> > wrote: > >> On Thu, Jul 27, 2017 at 7:49 PM, Norman Gaywood <ngayw...@gmail.com> >> wrote: >> >>> my $input = q:to/EOS/; >>> line of text >>> another line >>> EOS >>> >>> my $cat = run 'cat', '-n', :in($input.print), :out; >>> my $output = $cat.out.get; >>> $cat.in.close; >>> $cat.out.close; >>> >>> say "done"; >>> say $output; >>> >>> But that is not correct. I seem to be missing something. >>> >> >> :in, :out, :err want a filehandle (or will create one if you specify >> True, which is what pair syntax gives you if you specify one of them >> without a filehandle). Not a string; and .print applied to a Str does not >> turn the string into a filehandle, it sends the string to the filehandle in >> $*OUT. >> >> my $cat = run 'cat', '-n', :in, :out; >> $cat.in.print($input); # this .print, on IO::Handle, prints the string to >> that handle >> $cat.in.close; >> my $output = $cat.out.slurp: :close; >> >> Note that you need to be very careful to avoid the "open3" deadlock: >> pipes have limited buffers, and if you do this all in one thread when the >> data is large enough to block on write, and the receiving program then >> blocks on write back to you, you will deadlock. No language can protect you >> from this. The solution is that either the writer or the reader (or both) >> needs to be in its own thread so that if one blocks, the other can keep >> running and eventually clear the block. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net