@zhongdao 2018-12-21T05:16:06.000000Z 字数 13259 阅读 1066

# Signal in Perl

未分类

# 16.0. Introduction

Perl may be many things to many people, but to most of us it is the glue that connects diverse components. This chapter is about launching commands and connecting separate processes together. It's about managing their creation, communication, and ultimate demise. It's about systems programming.

When it comes to systems programming, Perl, as usual, makes easy things easy and hard things possible. If you want to use it as you would the shell, Perl is happy to assist you. If you want to roll up your sleeves for low-level hacking like a hardcore C programmer, you can do that, too.

Because Perl lets you get so close to the system, portability issues can sneak in. This chapter is the most Unix-centric chapter of the book. It will be tremendously useful to those on Unix systems, but of limited use to others. (If you're not on Unix, consult the perlport(3) manpage that came with Perl to see which of the techniques we describe are available on other operating systems or emulated by Perl.) We deal with features that aren't as universal as strings and numbers and basic arithmetic. Most basic operations work more or less the same everywhere. But if you're not using some kind of Unix or other POSIX conformant system, most of the interesting features in this chapter may work differently for you—or not at all. Check the documentation that came with your Perl port if you aren't sure.

You might even be pleasantly surprised. Windows users, for example, are often astonished to learn that Perl's fork function, long unique to Unix, is supported on their platform. See perlfork(1).

perl对很多人来说可能是很多东西，但对于我们大多数人来说，它是连接各种组件的胶水。本章介绍如何启动命令并将各个进程连接在一起。它是关于管理他们的创造，沟通和最终消亡。这是关于系统编程。

# 16.0.1 Process Creation

In this chapter, we cover the proper care and feeding of your own child processes. Sometimes this means launching a standalone command and letting it have its own way with the world (using system). Other times it means keeping a tight rein on your child, feeding it carefully filtered input or taking hold of its output stream (backticks and piped open s). Without even starting a new process, you can use exec to replace your current program with a completely different program.

16.0.1进程创建

We first show how to use the most portable and commonly used operations for managing processes: backticks, system, open, and the manipulation of the %SIG hash. Those are the easy things, but we don't stop there. We also show what to do when the simple approach isn't good enough.

For example, you might want to interrupt your program while it's running a different program. Maybe you need to process a child program's standard error separately from its standard output. Perhaps you need to control both the input and output of a program simultaneously. When you tire of having just one thread of control and begin to take advantage of multitasking, you'll want to learn how to split your current program into several, simultaneously running processes that all talk to each other.

For tasks like these, you have to drop back to the underlying syscalls: pipe, fork, and exec. The pipe function creates two connected filehandles, a reader and writer, whereby anything written to the writer can be read from the reader. The fork function is the basis of multitasking, but unfortunately it has not been supported on all non-Unix systems. It clones off a duplicate process identical in virtually every aspect to its parent, including variable settings and open files. The most noticeable changes are the process ID and parent process ID. New programs are started by forking, then using exec to replace the program in the child process with a new one. You don't always both fork and exec together, so having them as separate primitives is more expressive and powerful than if all you could do is run system. In practice, you're more apt to use fork by itself than exec by itself.

When a child process dies, its memory is returned to the operating system, but its entry in the process table isn't freed. This lets a parent check the exit status of its child processes. Processes that have died but haven't been removed from the process table are called zombies, and you should clean them up lest they fill the whole process table. Backticks and the system and close functions automatically take care of this, and will work on most non-Unix systems. You have more to worry about when you go beyond these simple portable functions and use low-level primitives to launch programs. One thing to worry about is signals.

# 16.0.2 Signals

Your process is notified of the death of a child it created with a signal. Signals are a kind of notification delivered by the operating system. They are used for errors (when the kernel says, "Hey, you can't touch that area of memory!") and for events (death of a child, expiration of a per-process timer, interrupt with Ctrl-C). If you're launching processes manually, you normally arrange for a subroutine of your choosing to be called whenever one of your children exits.

Each process has a default disposition for each possible signal. You may install your own handler or otherwise change the disposition of most signals. Only SIGKILL and SIGSTOP cannot be changed. The rest you can ignore, trap, or block.

16.0.2信号

Briefly, here's a rundown of the more important signals:

SIGINT
Normally triggered by Ctrl-C. This requests that a process interrupt what it's doing. Simple programs like filters usually just die, but more important ones like shells, editors, or FTP programs usually use SIGINT to stop long-running operations so you can tell them to do something else.
SIGQUIT
Also normally generated by a terminal, usually Ctrl-. Its default behavior is to generate a core dump.
SIGTERM
Sent by the kill shell command when no signal name is explicitly given. Think of it as a polite request for a process to die.
SIGUSR1 and SIGUSR2
Never caused by system events, so user applications can safely use them for their own purposes.
SIGPIPE
Sent by the kernel when your process tries to write to a pipe or socket when the process on the other end has closed its connection, usually because it no longer exists.
SIGALRM
Sent when the timer set by the alarm function expires, as described in Recipe 16.21.
SIGHUP
Sent to a process when its controlling terminal gets a hang-up (e.g., the modem lost its carrier), but it also often indicates that a program should restart or reread its configuration.
SIGCHLD
Probably the most important signal when it comes to low-level systems programming. The system sends your process a SIGCHLD when one of its child processes stops running—or, more likely, when that child exits. See Recipe 16.19 for more on SIGCHLD.
Signal names are a convenience for humans. Each signal has an associated number that the operating system uses instead of names. Although we talk about SIGCHLD, your operating system knows it only as a number, like 20 (these numbers vary across operating systems). Perl translates between signal names and numbers for you, so you can think in terms of signal names.

SIGINT

SIGQUIT

SIGTERM

SIGUSR1和SIGUSR2

SIGPIPE

SIGALRM

SIGHUP

SIGCHLD

# 16.14. Sending a Signal

## 16.14.1. Problem

You want to send a signal to a process. This could be sent to your own process or to another on the same system. For instance, you caught SIGINT and want to pass it on to your children.

## 16.14.2. Solution

Use kill to send a signal by name or number to the process IDs listed in the remaining arguments:

kill 9 => pid;                    # send$pid; # send$pid a signal 9
kill -1 => pgrp;                   # send whole job a signal 1
kill  USR1  =>
$pgrp; # send whole job a signal 1 kill USR1 =>$$; # send myself a SIGUSR1 kill HUP => @pids; # send a SIGHUP to processes in @pids ## 16.14.3. Discussion Perl's kill function is an interface to the syscall of the same name. The first argument is the signal to send, identified by number or by name; subsequent arguments are process IDs to send the signal to. It returns the count of processes successfully signaled. You can only send signals to processes running under the same real or saved UID as your real or effective UID—unless you're the superuser. Perl的kill函数是同名系统调用的接口。第一个参数是要发送的信号，由数字或名称标识; 后续参数是发送信号的进程ID。它返回成功发出信号的进程计数。除了您是超级用户之外，您只能向运行在与真实或有效UID相同的真实或已保存UID下的进程发送信号。 If the signal number is negative, Perl interprets remaining arguments as process group IDs and sends that signal to all those groups' processes using the killpg(2) syscall. 如果信号编号为负数，Perl会将剩余参数解释为进程组ID，并使用killpg（2）系统调用将该信号发送到所有这些组的进程 。 A process group is essentially a job. It's how the operating system ties related processes together. For example, when you use your shell to pipe one command into another, you've started two processes, but only one job. When you use Ctrl-C to interrupt the current job or Ctrl-Z to suspend it, this sends the appropriate signals to the entire job, which may be more than one process. 进程组本质上是一项工作。这是操作系统将相关过程联系在一起的方式。例如，当您使用shell将一个命令传递到另一个命令时，您已经启动了两个进程，但只启动了一个作业。当您使用Ctrl-C中断当前作业或使用Ctrl-Z暂停它时，它会将相应的信号发送到整个作业，这可能是多个进程。 kill can also check whether a process is alive. Sending the special pseudo-signal number 0 checks whether it's legal for you to send a signal to the process—without actually sending one. If it returns true, the process is still alive. If it returns false, the process either has changed its effective UID (in which case $! will be set to EPERM) or no longer exists (and$! is ESRCH). Zombie processes (as described in Recipe 16.19) also report back as ESRCH. kill也可以检查进程是否还活着。发送特殊的伪信号编号0会检查您是否合法地向进程发送信号 - 而不实际发送信号。如果它返回true，则该过程仍然存在。如果它返回false，则进程已更改其有效UID（在这种情况下$！将设置为EPERM）或不再存在（并且$！是ESRCH）。僵尸进程（如配方16.19中所述）也报告为ESRCH。 use POSIX qw(:errno_h);if (kill 0 =>$minion) {    print "$minion is alive!\n";} elsif ($! == EPERM) {             # changed uid    print "$minion has escaped my control!\n";} elsif ($! == ESRCH) {    print "$minion is deceased.\n"; # or zombied} else { warn "Odd; I couldn't check on the status of$minion: $!\n";} 16.14.4. See Also The "Signals" sections in Chapter 16 of Programming Perl and in perlipc(1); your system's sigaction(2), signal(3), and kill(2) manpages (if you have them); the kill function in Chapter 29 of Programming Perl and perlfunc(1) # 16.15. Installing a Signal Handler ## 16.15.1. Problem You want to control how your program responds to signals. You need to do this if you want to catch Ctrl-C, avoid accumulating finished subprocesses, or prevent your process from dying when it writes to a child that has gone away. ## 16.15.2. Solution Use the %SIG hash to install your own handler by name or by code reference: $SIG{QUIT} = \&got_sig_quit;     # call &got_sig_quit for every SIGQUIT $SIG{PIPE} = 'got_sig_pipe'; # call main::got_sig_pipe for every SIGPIPE $SIG{INT}  = sub { $ouch++ }; # increment$ouch for every SIGINT

%SIG also lets you ignore a signal:

$SIG{INT} = 'IGNORE'; # ignore the signal INT It also restores handling for that signal to the default: $SIG{STOP} = 'DEFAULT';          # restore default STOP signal handling

## 16.15.3. Discussion

Perl uses the %SIG hash to control what happens when signals are received. Each key in %SIG corresponds to a signal. Each value is the action to take when Perl receives the corresponding signal. Perl provides two special behaviors: "IGNORE" to take no action when a particular signal is received, and "DEFAULT" to perform the default Unix action for that signal.

Although a C programmer might think of a signal as SIGINT, Perl uses just INT. Perl figures you only use signal names in functions that deal with signals, so the SIG prefix is redundant. This means that you'll assign to \$SIG{CHLD} to change what your process does when it gets a SIGCHLD.

If you want to run your own code when a given signal is received, you have two choices of what to put in the hash: either a code reference or a subroutine name. (This means you can't name a signal handler IGNORE or DEFAULT if you store the string, but they'd be mighty strange names for signal handlers anyway.) If you use a subroutine name that isn't qualified by a package, Perl will interpret this name to be a function in the main:: package, not one in the package in which the handler was installed. A code reference refers to a subroutine in a particular package, so it is a better choice.

Perl calls your handler code with a single argument: the name of the signal that triggered it, such as "INT" or "USR1". Returning from a signal handler takes you back to whatever you were doing when the signal hit.

Perl defines two special signals, _ DIE _ and _ WARN _, whose handlers are called whenever a Perl program emits warnings through warn or dies through die. This lets you catch such warnings, and selectively trap or propagate them. The die and warn handlers are disabled while they run, so you can safely die from a _ DIE _ handler or warn from a _ WARN _ handler without fear of recursion.