Re: Ctrl-C on Win32

[Johan Holmberg]

I'll reply to myself ... :
>
> Can anyone confirm this undesirable behaviour,
> or maybe give an example where things works as expecteed.
>
> I don't think this is Cons fault, but instead Perl on Win32.
>


I have now re-read the passage on "signals" in the Camel (3rd
edition), and done some experimenting.

My conclusions:

- signals doesn't seem work at all on Win32 before 5.6

- signal somehow "work" in 5.6, but with the following caveats:

The Camel book says:

    [...]
    Notice that all we do in the signal handler is set a global
    variable and then raise an exception with die.
    Whenever possible try to avoid anything more complicated than
    that, because on most systems the C library is not re-entrant.
    Signals are delivered asynchronously(*), so calling any print
    function (or even anything that needs to malloc(3) more memory)
    could in theory trigger a memory fault [...]

    (*) Synchronizing singal delivery with Perl-level opcodes is
    scheduled for a future release of Perl, which should solve the
    matter of signals and core dumps.


So I think Cons does "too much" in it's signal handler.
Maybe Cons could be changed to just set a global variable
$main::ctrl_c, and then terminate "gracefully" at a later time in
Cons "main-loop".

I the cases that Cons is waiting in a system-call (which is the most
usual case) the exit code from "system" already indicates that
something went wrong, but the check for $main::ctrl_c is needed in
the other cases.

I have tested my ideas with 5.6 and it seem to work as expected,
but I don't know how to write a testcase for it (especially the
timing-dependent part).

Any thoughts ?

/Johan Holmberg