Re: POE::Kernel->stop() will trigger _stop in the next release

[Deven Parekh]

Hello,

Thank you for the quick response.

I will try to generate a test case for the above.

In the mean time if this helps, I did a hand edit to  the stop subroutine
in POE::Kernel and replaced

$self->_data_ses_stop($session->ID);

(which appears in the latest version )

with

$self->_data_ses_free($session->ID);

(which was how it was in previous version)

and the program is working as expected now.


I will try to generate a test case and send it for debugging.

Thanks in advance,

Best Regards.

On Tue, Nov 10, 2015 at 2:53 PM, Rocco Caputo  wrote:

> I don't expect the change to cause the behavior you've reported.
>
> If you can reduce your program to a self-contained test case, something I
> can run myself using only easily installed, public dependencies, I can
> investigate what happened.
>
> --
> Rocco Caputo 
>
> On Nov 10, 2015, at 15:12, Deven Parekh  wrote:
>
> Hello,
>
> Is it possible that it breaks the following capability of POE::Wheel::Run
> Running POE::Kernel in the Child
>
> Calling POE::Kernel->run() in the child process effectively resumes the
> copy of the parent process. This is rarely (if ever) desired.
>
> More commonly, an application wants to run an entirely new POE::Kernel
> instance in the child process. This is supported by first stop()ping the
> copied instance, starting one or more new sessions, and calling run()
> again. For example:
>
>   Program => sub {
> # Wipe the existing POE::Kernel clean.
> $poe_kernel->stop();
>
> # Start a new session, or more.
> POE::Session->create(
>   ...
> );
>
> # Run the new sessions.
> POE::Kernel->run();
>   }
>
> I had a program that used the above construct which works fine with
>
> POE  => $VERSION = '1.354';
>
> POE::Wheel::Run => $VERSION = '1.354';
>
>
> However with
>
> POE => $VERSION = '1.367';
> POE::Wheel::Run => $VERSION = '1.367';
>
> It seems calling POE::Kernel->stop(); it stops the POE::Kernel instance in 
> parent as well.
>
> Just wondering if the above change could be causing this behaviour (?)
>
> Thanks in advance.
>
> Best Regards
>
>
>
>
> On Thu, Oct 30, 2014 at 4:00 PM, Rocco Caputo  wrote:
>
>> Hello, everyone.  I hope you've been well.
>>
>> It's come to my attention that POE::Kernel->stop() isn't triggering _stop
>> handlers.  This seems wrong, so I've changed it.  I hope it doesn't break
>> anything, but I'm mentioning it here in case people want to check in
>> advance of a release.
>>
>> I've already run it past irc.perl.org #poe, and nobody objected.
>>
>> --
>> Rocco Caputo 
>
>
>
>

Re: POE::Kernel->stop() will trigger _stop in the next release

[Rocco Caputo]

Hi.  With the limited information I have, I'm guessing that you have _stop 
handlers with side effects that affect resources shared between parent and 
child.  For example, shutting down a socket that the parent still needs.  I 
wouldn't limit my investigation to that scope, but I would start there.

-- 
Rocco Caputo 

> On Nov 11, 2015, at 19:31, Deven Parekh  wrote:
> 
> Hello,
> 
> Thank you for the quick response.
> 
> I will try to generate a test case for the above.
> 
> In the mean time if this helps, I did a hand edit to  the stop subroutine in 
> POE::Kernel and replaced 
> 
> $self->_data_ses_stop($session->ID);
> 
> (which appears in the latest version )
> 
> with 
> 
> $self->_data_ses_free($session->ID);
> 
> (which was how it was in previous version)
> 
> and the program is working as expected now.
> 
> 
> I will try to generate a test case and send it for debugging.
> 
> Thanks in advance,
> 
> Best Regards.
> 
> On Tue, Nov 10, 2015 at 2:53 PM, Rocco Caputo  > wrote:
> I don't expect the change to cause the behavior you've reported.
> 
> If you can reduce your program to a self-contained test case, something I can 
> run myself using only easily installed, public dependencies, I can 
> investigate what happened.
> 
> -- 
> Rocco Caputo mailto:rcap...@pobox.com>>
> 
>> On Nov 10, 2015, at 15:12, Deven Parekh > > wrote:
>> 
>> Hello,
>> 
>> Is it possible that it breaks the following capability of POE::Wheel::Run
>> Running POE::Kernel in the Child <>
>> Calling POE::Kernel->run() in the child process effectively resumes the copy 
>> of the parent process. This is rarely (if ever) desired.
>> 
>> More commonly, an application wants to run an entirely new POE::Kernel 
>> instance in the child process. This is supported by first stop()ping the 
>> copied instance, starting one or more new sessions, and calling run() again. 
>> For example:
>> 
>>   Program => sub {
>> # Wipe the existing POE::Kernel clean.
>> $poe_kernel->stop();
>> 
>> # Start a new session, or more.
>> POE::Session->create(
>>   ...
>> );
>> 
>> # Run the new sessions.
>> POE::Kernel->run();
>>   }
>> 
>> I had a program that used the above construct which works fine with
>> POE  => $VERSION = '1.354';
>> POE::Wheel::Run => $VERSION = '1.354';
>> 
>> 
>> However with 
>> POE => $VERSION = '1.367';
>> POE::Wheel::Run => $VERSION = '1.367';
>> 
>> It seems calling POE::Kernel->stop(); it stops the POE::Kernel instance in 
>> parent as well.
>> 
>> Just wondering if the above change could be causing this behaviour (?)
>> 
>> Thanks in advance.
>> Best Regards
>> 
>> 
>> 
>> On Thu, Oct 30, 2014 at 4:00 PM, Rocco Caputo > > wrote:
>> Hello, everyone.  I hope you've been well.
>> 
>> It's come to my attention that POE::Kernel->stop() isn't triggering _stop 
>> handlers.  This seems wrong, so I've changed it.  I hope it doesn't break 
>> anything, but I'm mentioning it here in case people want to check in advance 
>> of a release.
>> 
>> I've already run it past irc.perl.org  #poe, and 
>> nobody objected.
>> 
>> --
>> Rocco Caputo mailto:rcap...@pobox.com>>
>> 
> 
>