in reply to the unsafe signals controversy

It seems to me that 'deferred signals' is a temporary workaround until the 'unsafe signals' can be made safe.
No, it's not temporary. The signals are safe because they are deferred. If they are not deferred, they aren't safe. It means if a signal arrives, and Perl is doing some work (which could mean altering the internal state - which that at the moment the signal arrives could be inconsistent) handling the signal is deferred until Perl is done and getting ready for the next task.
Do you use external programs or some other method to avoid using the unsafe signals?
Uhm, how would you use that? Signal the external program, which then signals the Perl program? That doesn't seem to gain anything, does it?

Abigail

Replies are listed 'Best First'.
Re: Re: the unsafe signals controversy
by jfroebe (Parson) on Mar 23, 2004 at 19:03 UTC
    Uhm, how would you use that? Signal the external program, which then signals the Perl program? That doesn't seem to gain anything, does it?

    The jist of it:

    Fork, execute operation in new process p2 which will update a file or some shared ipc on completion. P1 has a signal handler that will notify 'p1' if it was interrupted in a 'safe' area.

    In p1, use the alarm signal to 'timeout' p2. If update was not performed yet, send a SIGTERM (followed by a SIGKILL if necessary).try again.

    it is a kludge and not 100% full proof, but works ok in all the tests I've performed so far.

[reply]

In Section Seekers of Perl Wisdom