in reply to Re^3: Why are people not using POE?
in thread Why are people not using POE?

"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; }

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.

Replies are listed 'Best First'.
Re^5: Why are people not using POE?
by revdiablo (Prior) on Jun 10, 2005 at 22:59 UTC

    Fair points, all. Notice I didn't reply at all to the meat of your original post, because what you say is essentially true. There are circumstances where POE definitely does not make sense. If those circumstances are all you ever encounter, then so be it; don't use POE.

    I only take issue with your use of the term "global variables" to describe something different from what most people call global variables.

    Update: I think you are referring to the variable's duration where as I am thinking about the variable's scope. Both are valid things to consider, but I think scope is what most people think about when they call something Global or Local. Perhaps I am wrong, but that's the feeling I get.

      I agree that my use of the word "global" in this context is suboptimal.

      The classic example is a project I was on 20 odd years ago where the project leader had been told that using global variables (in C) was considered a no-no. So, his 'fix' to avoid globals was that instead of this:

      // projdata.h int something; char filename[255]; ... // projlib.c #include "projdata.h" int somefunc() { ... strupr( filename ); ... return 0; } void someotherfunc ( int n ) { ... something = n; ... return; }

      We had:

      // projdata.h struct { int something; char filename[255]; ... } projdata, *pprojdata; // projlib.c #include "projdata.h" int somefunc( pprojdata p ) { ... strcat( p->filename, ... ); ... return 0; } void someotherfunc ( pprojdata p, int n ) { ... p->something = n; ... return; } // main.c int main ( ... ) projdata pd; int n; ... n = somefunc( &pd ); ... someotherfunc( &pd, n ); ... }

      Everything was simply wrapped in a huge struct a pointer to which got passed to every subroutine in the project. That code may seem far-fetched, but beleive, it's like is not so far away even today.

      He'd avoided using global variables, but still all the program state was "global" in scope, even though it actually resided on the stack and so was local (auto) to main.

      Global is not the right term here, but I cannot think of a better term?


      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.