They do...if you try to do all of your computation within the window procedures/callbacks of the gui...which is why you don't.

You run the gui in it's own thread and move any potentially time-expensive or complex processing into other threads.

That way the code in the gui thread need only maintain that state, and perform that processing required to maintain the gui. Everything else get spun off into other threads where the work can be coded as if it were a standalone program. All the state required by the algorithm is local, and the flow linear.

Only the initiation and return of results are transferred between the gui and the work threads and that is done by posting messages via a queue.

The gui remains resposive no matter how much work the work threads do. And, in a crisis, the user can instruct the gui to kill the background thread (or just suspend it), if it takes too long or he changes his mind about the results he needs.

To achieve the same thing using POE (or Tk->repeat or Tk->after) means breaking the long processing into small bits (and maintaining the state across callbacks!), to ensure that the rest of the application remains responsive. That is tedious and error prone and how much work can be done in each callback will vary depending upon the performance of the processor it runs on.

So you tune it for your 4GHz development box and when it arrives on your customers 1.5 GHz machine, the gui runs like molasses. Or you tune it for the 1.5 GHz machine and it takes 3 times as long on another customers 4.0 GHz machine as it should do, because it spend 50% of it's time saving and restoring state around iddy-biddy runs of the callback. You cannot tune for both scenarios. And programming state machines is hard.

except your first point

Too bad his first point is not true. POE provides a heap storage hash to each session. Using package variables, or even file-scope lexicals, is nearly always unnecessary.

"Global" here doesn't relate to Perl's concept of package or file-scope variables. It just relates to non-local scoping.

You have a process that in a standalone, linear program might be a simple subroutine that uses a few local variables--but it takes several seconds to run. Say:

sub getFromDB {
    my $dbh = shift;
    my $sth = $dbh->prepare( 
        'SELECT (...) from ... left inner join ... union ... where ...
+ in ( select ... )' 
    )or die $dbi->errstr;
    return sth->fetchall_arrayref;
}
[download]

But that takes say 5 seconds to run.

With POE, you now have to break that up so that each part of the processing takes less than say 1/10th of a second, so that your program remains responsive to the sockets it is monitoring. That means breaking that 3 line sub into 50 pieces. Where do you start?

And you have to arrange for those 50 pieces to run in sequence. How?

And the local variables that Perl will clean up automatically, now have to persist across the callbacks. But what happens if something goes wrong part way through? You also have to add code to clean up afterwards.

With threads, that subroutine stays as is--simple. And the main thread stays responsive to the sockets.

And if something goes wrong in the thread, you just terminate it and spawn a new one. Clean up is automatic.

---

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

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

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

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.