Try to wrap your head around it again in some other way. As a guideline, you almost never want to call the recv method of AnyEvent condvars from event handlers.

#!/usr/bin/perl 
use warnings;
use strict;
use Glib;  

my $main_loop = Glib::MainLoop->new;

Glib::IO->add_watch (fileno 'STDIN', [qw/in/], \&watch_callback, 'STDI
+N');    

#just to show it's non blocking
my $timer1  = Glib::Timeout->add (1000, \&testcallback, undef, 1 );

$main_loop->run;

sub watch_callback {
#    print "@_\n";
    my ($fd, $condition, $fh) = @_;
    my $line = readline STDIN;
    print $line;
    #always return TRUE to continue the callback
    return 1;
}    

sub testcallback{
   print "\t\t\t".time."\n";

}
__END__
[download]

#!/usr/bin/perl
use strict;
use warnings;

use AnyEvent;

while (1) {
        my $cv = AE::cv;
        my (@output, @input);   
        my $input_waiting = AE::cv;
        my $output_waiting = AE::cv;

        my $input_from_stdin = AE::io *STDIN, 0, sub {
                my $input = <STDIN>; # read it
                push(@input, $input);
                $input_waiting->send;
        };

        # what to do when $input_waiting has sent
        $input_waiting->cb( sub {
                push(@output, 'done');
                $output_waiting->send;
        });

        # what to do when $output_waiting has sent
        $output_waiting->cb( sub {
                print shift(@output) ."\n";
                $cv->send;
        });

        # wait for the main condvar
        $cv->recv;

}
[download]

Thanks for your design input. As I mentioned in my previous reply to BrowserUk, I am tempted to walk away from event based programming for the task, at least for now.

But before I do I will give it a last try with your proposed structure. As I've learned from your post, redeclaring condvars over and over again seems to be okay to send the overall system into stop and start states, as I can use a cv only once.
I've already looked into the begin/end methods a bit, but so far did not need its "counter" mechanism. We'll see.

Again, thanks!

Sorry for this, but I'm going to ask what might be a really dumb question.

As I read your post: you can't process until you've obtained some input; and you can output until you've processed that input. Correct?

If so, that sounds like a serial process to me:

while( <> ) {
    ## do something to $_
    print;
}
[download]

So why would you use a behemoth like AnyEvent to do that?

I expected this to come up. And to be honest: I am not quite sure if AnyEvent should *really* stay onboard or not...

Well, the verbose explanation is that this input output thing here is part of a larger system, where multiple things go on simultaneously. AnyEvent's timers come in handy, I've got kind of a main-loop... stuff like that. So I thought: I think that's where others would throw an event framework into the mix. So when I needed to add this input/output interface here, a component which influences the various parts of the system, I thought it would be a consistent move to model this with AnyEvent's tools as well.
Wrong asumption?

So when I needed to add this input/output interface here, a component which influences the various parts of the system, I thought it would be a consistent move to model this with AnyEvent's tools as well. Wrong asumption?

Hm. Let me be up-front and say: I don't understand why anyone would voluntarily choose to use an event-driven system on a pre-emptive, multi-tasking operating system. The phrase that comes to mind is: "Like buying a dog and barking yourself".

It always reminds me of one of those plate-spinning acts. The guy or girl is running around splitting their time between trying to load up new plates onto poles, whilst keeping the existing ones spinning fast enough to stop them falling. Everyone gets behind them cheering them on. Unwittingly helping them out by collectively "whoooa"ing, whenever one of them starts to wobble violently. Eventually they either complete the poles available or their timeslot comes to an end and everyone applauds with admiration. But in the end, we all know they're all going to come crashing down.

In the past, I've had to program such systems, because there was no other option available. They can be made to work well, and can be very efficient. But at what expense? They are so complicated and fragile. Difficult to program; a nightmare to debug; and horrendously expensive to maintain. One change to the specification; or the need to move to different hardware; and you're into a game of having to re-tune every part of the system.

And once you're locked into a given framework, nearly everything you want to do requires a "special version" of everyday modules. Just witness the hundreds of modules that turn up when you search for AnyEvent::* or POE::*. And see how many of them are specially adapted versions of common, well used modules like ...::LWP::* and ...::NET::* and ...::IO::*. And then there are the dependency chains. A bug arises and a fix is a applied to one of those core modules, but then you have to wait for that fix to make it's way through the chain into the specialist version you're using.

Their proponents will tell you horror stories of deadlocks and inversion chains, and all sorts of other nasties, if you bring up threads; but as you've discovered, you don't avoid synchronisation issues with an event-based system. Indeed, you have to use it to try re-create a simple serial sequence of DoA() then DoB() then DoC().

You want to read-process-write, see the loop above. You need to do other things while that goes on:

async{
    while( <> ) {
        ## process $_
        print;
    }
};
[download]

Now you can!

Let that well-tested, highly tuned, pre-emptive multi-tasking scheduler take care of making sure that when things need doing, they get done. None of this interrupting everything you're doing, every 1/10th of a second, to run around everywhere else asking (polling): Does anything need doing? Does anything need doing?

Don't feel the need to counter this--it's just my view on things--but I've yet to see an event-driven application that wasn't simpler written and maintained using threading. That's actually a challenge that I'd love to see someone take up. But I doubt they will. I'll let you decide the reason why not :)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy