Greetings,
Thanks for the tips, I have started reading and I think I am starting to get it... I would like to summarize my present understanding so that you can correct me:

When you make the call, give the callbacks and such you are stating that "in case of event on this channel, this is what I want to be done".
This decision is completely independent from any condvar send or recv, since such action does not have to involve any of this.
If you want your program to wait for events on a specific channel (or combinations thereof) then you start putting condvars, with a producer inside the callback and a receiver wherever you want the program to block until the event happens.

The trick being, your program state is now (or at least in that paradigm) dictated by whatever data comes down the pipes and how you want to deal with it. One could classify such data as either blocking or non blocking. Non blocking data being able to change the program state in small ways, blocking data requiring the program to wait for it and then react.

Now onto the "main loop", such program could do completely without one (and even without a condvar if the window in which the program looks for the event is very small?) if it only waits for one event.

Classic while or for loops are useless for this since those loops depend on the internal state of the program, not the state of an external system which data comes down the pipes.
Hence when writing the main program one has to state the different events one is watching and how they will change the program state.

such a loop, when using anyevent is defined like this:

use Anyevent;
...
...
some more code watching for events
...
...
Anyevent::condvar->recv
[download]

One has to understand though that this loop wont be interrupted whatever the internal state of the program might become, if one wanted the program to be able to terminate itself one would have to use a condvar that is produced somewhere inside the loop:

use Anyevent;
...
some code
...
event loop with a shoot_myself_in_the_mouth condvar
...
shoot_myself_in_the_mouth->recv;
[download]

Now I think I can discern more clearly the design challenges I am faced with:
Waiting for an internally specified time, checking an internal variable for changes that could have happened during that time.

Acting upon it.

Blocking on another event channel that would indicate the effects of my actions

going back to square one until externally terminated:

connect_to_event_source_one;
connect_to_event_source_two;
use Anyevent;


sleep($sometime);

if($internal_variable == $something_else){
      do_some_action;
      event_source_two recv;
     if($internal_variable2 == $new_expected_external_state)    {
     yet_another_action;
     }
}
Anyevent::condvar->recv;
[download]

Update: some cleanup

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.