On Mon, 05 Mar 2001 23:45:06 -0800, Peter Scott wrote:

[ In reference to the code in <[EMAIL PROTECTED]> ]

>May I ask a few questions about the code?  I'm copying the list in case 
>someone here is keeping up with it.  I'm just trying to get this under my 
>belt.  I have been reading the documentation really thoroughly, believe 
>me.  In fact I had another five questions here which I've managed to delete 
>through sufficient reading.
>
>The reason for putting the new SocketFactory on the heap in 
>$heap->{connector} is to keep it alive, is that right?  Otherwise if the 
>return value were stored in something that went out of scope too soon, e.g.,
>
>   my $connector = POE::Wheel::SocketFactory->new
>
>instead of
>
>   $heap->{connector} = ...
>
>then the SocketFactory would be destroyed and its _stop state called when 
>the current routine returned, do I have that right?

This is partially true.  The SocketFactory (and the other Wheel
subclasses) works in some ways like a plain Perl object, and its
DESTROY method is called when it goes out of scope.  Since a heap
persists as long as its Session instance, saving the SocketFactory
reference there ensures that it won't accidentally go out of scope.

It's also partly false.  See the next session for more information
about Session destruction.


>The fail() method ends by clearing any pending timeouts.  Since you've just 
>deleted the reference to its session in $heap->{connector}, what would 
>happen if you didn't clear them?  Could a timeout be delivered to a 
>nonexistent session?  The _stop state of the session (if there were one) 
>would get called as soon as the fail() method returns, 
>right?  Doesn't/shouldn't this clear any pending timeouts?

No, the Session would linger until the timeouts became due.

Generally speaking, POE::Kernel tracks six resources used by every
Session.  A Session is stopped automatically when all six of its
resource counts drop to zero.  Here's a complete list of resources
that affect a Session's reference counts:

  Plain events
  Pending timers
  Child sessions
  Selected filehandles
  Aliases
  "Extra" references

I say "generally speaking" because Sessions are sometimes destroyed
when they still have resources allocated.  Consider signals and
similar things.  In those cases, POE::Kernel knows the resources are
still active, and it cleans them up as best it can on behalf of the
departed Sessions.

So, no, you need to clear the timer explicitly.  In fact, I hadn't
done that to start with, and the pop3 checker always failed with a
timeout.


I've done my job if your net confusion has dropped.

-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net


Reply via email to