in reply to POE::Wheel::ReadWrite: "low priority" events

Here's the long way, which doesn't assume you know the minimum length of input records. I've added copious comments to make this more tutorial-like.

use warnings; use strict; use POE qw(Wheel::ReadWrite); my $S2 = POE::Session->create( inline_states => { _start => sub { $_[HEAP]->{input_buffer} = [ ]; $_[HEAP]->{reader} = POE::Wheel::ReadWrite->new( Handle => \*STDIN, InputEvent => 'got_input', ErrorEvent => 'got_input_error', ); }, got_input => \&handle_input, got_input_error => \&handle_input_error, step_one => \&do_step_one, step_two => \&do_step_two, process_next_input => \&process_next_input, } ); POE::Kernel->run(); exit; sub handle_input { # Buffer the input rather than process it immediately. my $buffered_count = push @{ $_[HEAP]{input_buffer} }, $_[ARG0]; # If this is the first input record in the buffer, then begin # processing input. We don't need to begin every time, since the # rest of the code will continue to process input as long as there's # something in the buffer. # However, we do want to pause the reader's input, since otherwise # it might slurp an entire file or stream into the input buffer # while we're doing something else. # Note that we can't just pause_input() if we want to handle one # input record at a time. For efficiency, POE::Wheel::ReadWrite may # have read multiple input records at once. if ($buffered_count == 1) { $_[HEAP]{reader}->pause_input(); $poe_kernel->yield('process_next_input'); } } # Stop the reader on input error, which may simply be EOF. # The program exits shortly afterwards. # It may be useful to print the error later on. sub handle_input_error { delete $_[HEAP]{reader}; } sub process_next_input { # Get the next job from the input buffer. my $next_input = shift @{ $_[HEAP]{input_buffer} }; # If there was no next input, then resume input so more jobs can be # acquired from STDIN. unless (defined $next_input) { $_[HEAP]->{reader}->resume_input(); return; } # Simulate multi-event asynchronous work. print "Next input: $next_input\n"; $_[KERNEL]->yield('step_one', $next_input); } sub do_step_one { print " step one: $_[ARG0]\n"; $_[KERNEL]->yield('step_two', $_[ARG0]); } sub do_step_two { print " step two: $_[ARG0]\n"; $_[KERNEL]->yield('process_next_input'); }

Replies are listed 'Best First'.
Re^2: POE::Wheel::ReadWrite: "low priority" events
by vlad_s (Novice) on Jan 20, 2012 at 18:11 UTC

    Thank you very much Rocco, the idea is clear.

    However this assumes that we know which event is issued last - because that event must issue 'process_next_input'.

    What if we don't know that - the number and order of events that get generated in the course of processing of a line is more or less random?

    I changed your sample so that event step_two sometimes gets issued and sometimes doesn't. Also I added checking get_event_count() to see if there are any further events in the queue. Seems that achieved my goal:

    sub do_step_one { print " step one: $_[ARG0]\n"; $_[KERNEL]->yield('step_two', $_[ARG0]) if rand(1) > 0.5; $_[KERNEL]->yield('process_next_input') if $poe_kernel->get_event_co +unt() == 0; } sub do_step_two { print " step two: $_[ARG0]\n"; $_[KERNEL]->yield('process_next_input') if $poe_kernel->get_event_co +unt() == 0; }

    Thanks once again for your time!

      You could implement the Chain of Responsibility design pattern by promoting ARG0 from an input string to a data structure that includes the input and the steps to process it.

      First define a subroutine to pass the job to the next step in the recipe:

      sub what_next { my ($kernel, $job) = @_; my $next_step = shift @{ $job->{recipe} }; if (defined $next_step) { $kernel->yield( $next_step => $job ); } else { $kernel->yield( 'process_next_input' ); } }

      process_next_input() builds the job and the initial recipe, and then uses what_next() to start the process:

      sub process_next_input { ...; my $job = { input => $next_input, recipe => [ 'step_one', 'step_two' ], }; what_next($_[KERNEL], $job); }

      All stages of the process end by calling what_next() to pass the work on. You could get fancy by pushing coderefs onto the recipe that conditionally return the next event in the chain.

      Sorry for not responding in so long. I'm doing PerlMonks wrong, and I don't notice my message inbox until I actively return to the site. If there's some sort of RSS-like way to check for messages, that would help a lot.

        I don't notice my message inbox until I actively return to the site.

        That's the way PerlMonks works; you're not doing it wrong. Unfortunately we don't (yet) have any other way of notifying users of events of interest, e.g. via email.

        If there's some sort of RSS-like way to check for messages, that would help a lot.

        Or that. :-)

        I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.