Bug #68021 for Test-Corpus-Audio-MPD: [Feature Request] Add shutdown hooks

Sun May 08 10:10:05 2011 KENTNL [...] cpan.org - Ticket created

Subject:

[Feature Request] Add shutdown hooks

At present, if the Perl interpreter is terminated for an unusual reason, END may not get called, as demonstrated by this snippet:

perl -e 'while(1){ } END { print "END" } '
^C

its evident to note that ^C stops the END being reached, despite it being a legitimate way to terminate the process. This leaves a spawned mpd child floating around unreaped which is somewhat annoying.

perl -MTest::Corpus::Audio::MPD
^C

perl -MTest::Corpus::Audio::MPD
mpd is running
Compilation failed in require.
BEGIN failed--compilation aborted.

This is somewhat undesirable, but its not really a critical feature which is why I've wish-listed it.

Mon May 09 07:44:18 2011 jquelin [...] cpan.org - Correspondence added

On Sun May 08 10:10:05 2011, KENTNL wrote: Show quoted text

> its evident to note that ^C stops the END being reached, despite it

being a Show quoted text

> legitimate way to terminate the process. This leaves a spawned mpd child > floating around unreaped which is somewhat annoying.

erm. sending sigterm is not a "legitimate" way to terminate a process. i'd say that in this case, it's not really up to the module to clean up afterwards, is it? i'd hate having to add a signal handler, since that's just crazy to me. i'd tend to close this bug as invalid... how would you do what you require?

Mon May 09 07:44:19 2011 The RT System itself - Status changed from 'new' to 'open'

Mon May 09 12:07:50 2011 KENTNL [...] cpan.org - Correspondence added

On 2011-05-09 23:44:18, JQUELIN wrote:
Show quoted text

> erm. sending sigterm is not a "legitimate" way to terminate a process.
> i'd say that in this case, it's not really up to the module to clean up
> afterwards, is it?

Its just that most of the time, when you kill a process via ^C, you expect that it will clean up its children, and the majority of the time, what I expect tends to be true, in that children who are still attached to the process are killed.

Its somewhat unnerving to experience any code that has some sort of "temporal persistence" in memory *after* its terminated.

Show quoted text

>
> i'd hate having to add a signal handler, since that's just crazy to me.
> i'd tend to close this bug as invalid...
>
> how would you do what you require?

Granted its possibly very confusing as to how to do it "right", I contemplated stuffing something in $SIG{INT} , but its difficult to know how to do this in a module in a way that it makes sense in the context of any consuming application.

I'd propose this be left as an open feature request until we can find some reasonable way of addressing this concern, the very least of which would be documenting it.

I don't know exactly if code in DESTROY calls are triggered either during ^C interrupts , but if they are, you could maintain the automated reaping with some code in a object destruction.

I'd probably have to find other code on CPAN which does anything like this in a reliable fashion and stealing their code, or asking around and seeing if anyone has any advice on how to do it cleanly.

Tue May 10 06:22:02 2011 jquelin [...] cpan.org - Correspondence added

On Mon May 09 12:07:50 2011, KENTNL wrote: Show quoted text

> Its somewhat unnerving to experience any code that has some sort of > "temporal > persistence" in memory *after* its terminated.

agreed. Show quoted text

> Granted its possibly very confusing as to how to do it "right", I > contemplated > stuffing something in $SIG{INT} , but its difficult to know how to do > this in a > module in a way that it makes sense in the context of any consuming > application.

note also the very specific use case of this module, which is just to provide some test data to mpd modules instead of duplicating in audio::mpd and pococ::mpd Show quoted text

> I'd propose this be left as an open feature request until we can find > some reasonable way of addressing this concern, the very least of > which would be documenting it.

ok, if you have any good idea that would enhance the behaviour, i'd be most willing to merge it.