24 작업 제어

작업제어는 단일한 로그인 세션에서 사용자가 여러개의 프로세스 그룹들(또는 작업들) 사이에서 제어를 옮기는 것을 허용하는 프로토콜을 적용한다. 작업제어 기능은 대부분의 프로그램에서 자동적으로 적당하게 수행되고, 작업제어에 대한 특별한 어떤 것을 할 필요가 없다. 그래서 당신이 쉘이나 로그인 프로그램을 만들지 않는다면 이 장에 있는 것들을 무시할 수 있다.

당신이 이 장에 나와있는 것들을 이해하기 위해서는 시그널 핸들링(21장 [Signal Handling] 참조)과 프로세스 생성(23.2절 [Process Creation Concepts] 참조) 과 연관된 개념에 친숙해질 필요가 있다.

24.1 작업제어의 개념

대화형(interactive) 쉘의 기본적인 목적은 사용자 터미널로부터 명령문을 읽고 그 명령문에의해 지정된 프로그램을 실행하도록 프로세스들을 만드는 것이다. 그것은 fork( 23.4절 [Creadting a Process] 참조.)와 exec ( 23.5절 [Executing a File] 참조.)함수를 사용해서 할 수 있다.

단일한 명령문은 단지 한 개의 프로세스를 실행시키지만_종종 한 개의 명령문도 여러개의 프로세스들을 사용한다. 만일 당신이 쉘 커맨드에서 `|'을 사용한다면 당신은 명시적으로 그들 프로세스안에 여러개의 프로그램들을 요청한것이다. 그러나 만일 당신이 한 개의 프로그램을 실행시킬지라도, 그것이 내부적으로는 여러개의 프로세스들을 사용할 수 있다. 예를들어, `cc -c foo.c'와 같은 단일한 컴파일 명령문은, 전형적으로 네 개의 프로세스들을 사용한다. 만일 당신이 make를 실행한다면, 그 작업은 분리된 프로세스 안에서 다른 프로그램을 실행하는 것이다.

단일한 명령문에 소속되어 있는 프로세스들은 프로세스 그룹이나 작업(job)이라고 불린다. 당신은 동시에 그들 모든 프로세스들을 작동시킬 수 있다. 예를들어, C-c를 타이핑하면 전면 프로세스 그룹에 있는 모든 프로세스가 종료되도록 시그널 SIGINT를 보낸다. 세션은 프로세스들의 좀 큰 그룹이라고 할 수 있다. 일반적으로 단일한 로그인에 있는 모든 프로세스들은 같은 세션에 속한다.

모든 프로세스는 프로세스 그룹에 속한다. 어떤 프로세스가 만들어질 때, 그것은 부모 프로세스와 같은 프로세스 그룹과 세션의 멤버가 된다. 당신은 setpid 함수를 사용해서 다른 프로세스 그룹으로 소속을 바꿀 수 있는데, 그때 그 프로세스 그룹은 같은 세션에 소속된 프로세스 그룹이다.

다른 세션에 프로세스를 소속시키는 유일한 방법은 setsid 함수를 사용해서, 새로운 세션이나, 또는 세션 리더의 처음 프로세스를 만드는 것이다. 새로운 프로세스 그룹에 세션리더를 소속시키면, 당신은 다시 프로세스 그룹의 외부로 그것을 다시 옮길 수 없다.

보통, 새로운 세션들은 시스템 로그인 프로그램에 의해 만들어지고 세션 리더는 사용자의 로그인 쉘을 실행시키는 프로세스이다. 작업제어를 지원하는 쉘은 어떤 시간에 어떤 작업이 터미널을 사용할 수 있도록 제어를 조정해야만 한다. 그렇지않다면 여러개의 작업들이 동시에 터미널로부터 입력을 받아들이려 시도할것이고, 어떤 프로세스가 사용자가 타입한 입력을 받을 것인지가 혼란하게 될 수도 있다. 이것을 방지하기 위해서, 쉘은 이 장에 설명된 프로토콜을 사용해서 터미널 드라이버와 협력해야만 한다.

쉘은 한 번에 오직 한 프로세스 그룹에게만 터미널을 제어하는 제한없는 권한을 줄 수 있다. 이처럼 터미널을 제어하고 있는 프로세스 그룹을 전면 작업(foreground job)이라고 부른다. 터미널을 억세스 하지 않고 실행중인, 쉘에 의해 처리되고 있는 다른 프로세스 그룹들은 배경작업(background job)이라고 불린다.

만일 배경 작업이 터미널을 제어하여 터미널로부터 읽거나 쓰거나 할 필요가 있다면, 그것은 터미널 드라이버에 의해 멈추어진다. 사용자는 SUSP문자( 12.4.9절 [Special Characters] 참조)를 입력함으로써 전면 작업을 멈출 수 있고 프로그램은 SIGSTOP시그널을 보냄으로써 어떤 작업을 멈출 수 있다. 작업들이 멈추었을 때 쉘은 그들에 대하여 사용자에게 알릴 책임이 있고, 멈추어진 작업에 대해서 계속 진행할 것인지에 대한 여부를 사용자에게 선택하도록 허용하기 위한 메카니즘의 제공과 전면 작업과 배경 작업사이의 작업전환도 쉘에게 책임이 있다. 제어중인 터미널에 입/출력 하는것에 대한 자세한 정보는 24.4절 [Access to the Terminal] 참조.

24.2 작업제어는 선택적이다

모든 운영체제가 작업제어를 지원하는 것은 아니다. GNU 시스템은 작업제어를 지원하지만, 만일 다른 시스템에서 GNU 라이브러리를 사용한다고해도 그 시스템에서 작업제어를 지원하지 않을 수 도 있다. 당신은 시스템이 작업제어를 지원하는지에 대한 여부를 시험하기 위해서 컴파일할 때 _POSIX_JOB_CONTROL 매크로를 사용할 수 있다. 27.2절[System Options] 참조.

만일 작업제어가 지원되지 않으면, 한 세션만다 오직 한 개의 프로세스 그룹만 존재하고 그 프로세스 그룹은 항상 전면 작업으로써 행동한다. 부가적인 프로세스 그룹을 만드는 함수에는 에러코드 ENOSYS를 사용해서 간단히 실패했음을 알린다.

다양한 작업제어 시그널(21.2.5절 [Job Control Signals] 참조.)들을 대표하고 있는 매크로들은 작업제어가 지원되지 않는다고 할지라도 정의되어 있다. 그렇지만, 작업제어를 지원하지 않는 시스템에서 그 시그널들을 결코 발생되지 않고, 에러를 보고하거나 아무것도 하지않는 등의 시그널에 대한 행동을 정하거나 시험하거나 보내려고 시도하지 않는다.

24.3 프로세스의 터미널 제어하기

프로세스의 속성들중 하나는 그 프로세스가 제어중인 터미널이다. fork를 사용해서 만들어진 자식 프로세스는 그들의 부모 프로세스로부터 제어중인 터미널을 상속받는다. 이와같은 방법으로, 한 세션안에 있는 모든 프로세스들은 세션 리더(session leader)로부터 제어중인 터미널을 상속받는다. 터미널의 제어권을 가진 세션리더를 터미널의제어중인 프로세스(controlling process)라고 불린다.

당신이 로그인할 때 시스템이 당신을 위해서 그 일을 하기 때문에, 당신은 세션에 터미널 제어권을 할당하는 정확한 메카니즘에 대해서는 걱정할 필요가 없다. 개별적인 프로세스가 새로운 세션의 리더가 되기위해서 setsid를 호출할 때, 그 프로세스는 제어중인 터미널로부터 단절된다.

24.4 제어중인 터미널 억세스

터미널을 제어하고 있는 전면작업안의 프로세스들은 터미널에 대한 제한 없는 억세스 권한을 가진다; 배경프로세스들은 권한을 가지지 않는다. 이 절에서는 배경작업에 있는 프로세스가 터미널을 제어하려 시도할 때 어떤 일이 발생하는지에 대해서 자세히 설명하고 있다.

배경작업에 있는 프로세스가 전면작업이 제어하고 있는 터미널로부터 읽으려 시도할 때, 프로세스 그룹은 SIGTTIN 시그널을 받는다. 이것은 그룹안에 있는 모든 프로세스들의 동작을 멈추게 하는 원인이 된다(그 시그널이 처리되지 않거나 그들 스스로 멈추게 하지 않는다면). 그렇지만 읽기를 시도한 프로세스가 이 시그널을 무시하거나 블록한다면, 대신에 EIO 에러를 얻게 될 것이다.

유사하게, 배경작업에 있는 프로세스가 전면작업에서 제어하고 있는 터미널에 출력을 시도한다면, 그것에 대응된 디폴트 동작은 프로세스 그룹에게 SIGTTOU 시그널을 보내는 것이다. 그렇지만, 그 동작은 지역 모드 플래그(local modes flags)(12.4.7절 [Local Modes] 참조.)의 TOSTOP 비트에 의해서 갱신된다. 만일 이 비트가 설정되지 않는다면(이것이 디폴트이다.), 전면 작업에 의해 제어중인 터미널에 배경작업이 출력을 시도하는 것에는 시그널을 보내지 않고 항상 허가된다. 또한 출력을 시도하는 프로세스에 의해 SIGTTOU 시그널이 무시되거나 블록된다면 이때도 출력은 허가된다.

프로그램에서 할 수 있는 터미널 명령들의 대부분은 입력이나 출력을 위한 것이다. 기본적인 입력과 출력 함수에 대한 정보는 8.2절 [I/O Primitives] 참조.

24.5 고아가된 프로세스 그룹들

터미널 제어중이던 프로세스가 종료되면, 그 터미널은 해제되고 새로운 세션에 의해서 다시 제어될 수 있다.(실제로, 다른 사용자가 터미널 상에서 로그인 할 수 있다.) 이것은 만일 예전의 세션에 있는 어떤 프로세스가 그 터미널을 계속 사용하려고 시도한다면 문제가 발생할 수 있다.

그러한 문제들을 막기위해서, 세션리더가 종료된 후에도 계속 실행되고 있는 프로세스 그룹들은 고아가된 프로세스 그룹으로써 표시된다. 고아 프로세스 그룹(orphand process group) 안에 소속된 프로세스들은 터미널에 읽거나 쓰기를 할 수 없다. 만일 그렇게 하려 시도한다면 EIO 에러를 얻게 될 것이다.

어떤 프로세스 그룹이 고아가 되었을 때, 그 프로세스들은 SIGHUP 시그널을 받는다. 보통, 이것은 프로세스를 종료시키는 원인이 된다. 그렇지만, 만일 프로그램이 이 시그널을 무시하거나 시그널을 위한 핸들러를 만들었다면(21장 [Signal Handling] 참조.), 터미널을 제어중이던 프로세스가 종료되었다고 하더라도 실행중이던 고아 프로세스들은 계속 그 작업을 수행할 수 있다; 그렇지만 더 이상은 터미널의 억세스를 시도할 수 없다.

24.6 작업제어 쉘 실행시키기

이 절은 쉘이 작업 제어를 수행하기 위해서는 무엇을 해야만 하는지, 그 개념이 포함된 간단한 예제 프로그램을 통해서 설명하고 있다.

24.6.1절 [Data Structures]

이곳에서는 그 예제를 소개하고, 주요한 데이터 구조체를 소개하고 있다.

24.6.2절 [Initializing the Shell]

쉘이 작업제어를 준비하기 위해서 수행해야만 하는 동작들에 대해서 논의하고 있다.

24.6.3절 [Launching Jobs]

명령문을 실행하기 위해서 어떻게 작업들을 만들것이지에 대한 정보가 포함되어 있다.

24.6.4절 [Foreground and Background]

배경작업에 대립하는것으로써 전면으로 작업을 진출시킬 때 쉘이 무엇을 다르게 해야 만하는지를 설명하고 있다.

24.6.5절 [Stoppend and Terminated Jobs]

쉘에게 작업상황을 보고하기에 대해서 설명한다.

24.6.6 [Continuing Stopped Jobs]

작업이 멈추어졌을 때 다시 계속하기 위해서 어떻게 해야하는지를 설명한다.

24.6.7 [Missing Pieces] : 쉘의 다른 부분들에 대해서 설명하고 있다.

 

24.6.1 쉘을 위한 데이터 구조체들

이 장에 포함된 모든 예제 프로그램들은 간단한 쉘 프로그램의 일부분이다. 이 절은 이 예제에서 사용되고 있는 데이터 구조체와 유틸리티 함수들을 설명하고 있다.

간단한 쉘은 주로 두 개의 데이터 구조체를 다룬다. job 타입(type)은 파이프(pipes)로 서로 연결된 서브프로세스들의 집합인 작업에 대한 정보를 포함한다. process 타입(type)은 단일한 서브프로세스에 대한 정보를 저장하고 있다. 다음은 적절한 데이터 구조체 선언들이다.

/* process는 한 개의 단일한 프로세스이다. */
typedef struct process
{
struct process *next; /* 파이프라인에 있는 다음 프로세스 */
char **argv; /* exec을 위한 */
pid_tpid; /* 프로세스 ID */
char completed; /* 프로세스가 수행되었으면 참이다. */
char stopped; /* 만일 프로세스가 멈추었으면 참이다. */
int status; /* 보고된 상황들의 값 */
} process;
/* job 은 프로세스들의 파이프라인이다. */
typedef struct job
{
struct job *next; /* 다음 활동할 작업 */
char *command; /* 메시지를 위해서 사용되는, 커맨드 라인 */
process *first_process; /* 작업안에 있는 프로세스의 리스트 */
pid_t pgid; /* 프로세스 그룹 ID */
char notified; /* 사용자가 멈춘 작업에 대해서 말했으면 참이다. */
struct termios tmodes; /* 저장된 터미널 모드들 */
int stdin, stdout, stderr; /* 표준 입/출력 채널들 */
} job;
/* 활성화된 작업들은 리스트안에 연결되어 있고 이것이 그 헤드(head)이다.*/
job *first_job = NULL;
다음은 작업 오브젝트들은 운영하기 위해서 사용되는 유틸리티 함수들에 대한 것이다.
/* pgid를 통해서 활성 작업을 찾아라. */
job *
find_job (pid_t pgid)
{
job *j;
for (j = first_job; j; j = j->next) {
if (j->pgid == pgid)
return j;
}
return NULL;
}
/* 만일 job 안에 있는 모든 프로세스들이 완료되었거나 멈추어있다면 참을 리턴한다 */
int
job_is_stopped (job *j)
{
process *p;
for (p = j->first_process; p; p = p->next) {
if (!p->completed && !p->stopped)
return 0;
}
return 1;
}
/* 만일 job 안에 있는 모든 프로세스들이 완료되었다면 참을 리턴 */
int
job_is_completed (job *j)
{
process *p;
for (p = j->first_process; p; p = p->next) {
if (!p->completed)
return 0;
}
return 1;
}

 

24.6.2 쉘 초기화하기

일반적으로 작업제어를 수행하는 쉘 프로그램이 시작될 때, 그 쉘이 이미 자신의 작업제어를 수행하고 있는 다른 쉘로부터 호출되었을 경우에는 주의를 해야만 한다. 서브쉘(subshell)에서 작업제어가 가능하게 되기전에 우선 부모 쉘에 의해서 전면에 놓여져야만 한다. 그것은 getpgrp로 초기 프로세스 그룹 ID를 얻고, 현재 터미널을 제어하고 있는 전면작업의 프로세스 그룹 ID와 그것을 비교해서 한다( tcgetpgrp함수를 사용해서 추출될 수 있다. )

만일 그 서브쉘이 전면 작업으로써 실행되고 있지 않다면, 그것은 그 자신의 프로세스 그룹에 SIGTTIN 시그널을 보냄으로써 스스로 멈춰야만 한다. 그것은 전면에 그 자신을 제멋대로 놓을수 없다; 사용자가 부모 쉘에게 이것을 시키도록 기다려야만 한다. 만일 그 서브쉘이 계속된다면, 검사를 반복하고 만일 그것이 여전히 전면에 있지 않다면 다시 스스로 멈춘다.

일단 서브쉘이 부모 쉘에 의해서 전면에 놓이게되면, 서브쉘은 자신의 작업 제어가 가능하게 된다. 자신소유의 프로세스 그룹안에 그 자신이 놓이도록 setpgid를 호출하고, 그다음 전면에 이 프로세스 그룹이 놓이도록 tcsetpgrp를 호출함으로써 이러한 일을 한다.

쉘이 작업제어가 가능하게 되었을 때, 작업제어를 멈추도록 하는 모든 시그널에 대해서 무시하도록 그 자체에서 설정하기 때문에 그 자체는 우연히 멈추게 되지 않는다. 당신은 모든 멈춤 시그널들을 SIG_IGN 으로 설정하여 이러한 일을 할 수 있다.

비-대화식으로 실행되는 서브쉘은 작업제어가 지원되지도 않고 지원될 수도 없다. 그것은 그자체가 쉘인 프로세스 그룹안에 만든 모든 프로세스가 존재해야만 한다; 이것은 비-대화실 쉘과 부모 쉘에 의해 단일한 작업으로 취급되는 자식 프로세스를 허용한다. 이것은 작업제어를 사용하지 않지만 그것을 하는 쉘을 만들기 위해서는 기억해야만 한다.

다음은 이러한 모든 것을 어떻게 하는지 보여주는 예제 쉘을 위한 초기 코드이다.

/* 쉘의 속성을 기억하라. */
#include <sys/types.h>
#include <termios.h>
#include <unistd.h>
pid_t shell_pgid;
struct termios shell_tmodes;
int shell_terminal;
int shell_is_interactive;
/* 진행하기 전에 쉘이 전면작업으로써 대화식으로 실행되고 있는지를 확인하라. */
void
init_shell ()
{
/* 만일 대화식으로 실행된다면 보아라. */
shell_terminal = STDIN_FILENO;
shell_is_interactive = isatty (shell_terminal);
if (shell_is_interactive)
{
/* 전면에 놓일때까지 루프를 돈다. */
while (tcgetpgrp (shell_terminal) != (shell_pgid = getpgrp()))
kill (- shell_pgid, SIGTTIN);
/* 대화와 작업-제어 시그널들을 무시하라. */
signal (SIGINT, SIG_IGN);
signal (SIGQUIT, SIG_IGN);
signal (SIGTSTP, SIG_IGN);
signal (SIGTTIN, SIG_IGN);
signal (SIGTTOU, SIG_IGN);
signal (SIGCHLD, SIG_IGN);
/* 우리소유의 프로세스 그룹에 우리자신을 넣어라. */
shell_pgid = getpid ();
if (setpgid (shell_pgid, shell_pgid) < 0) {
perror("Couldn't put the shell in its own process group");
exit (1);
}
/* 터미널의 제어를 잡아라 */
tcsetpgrp (shell_terminal, shell_pgid);
/* 쉘을 위한 디폴트 터미널 속성을 저장하라. */
tcgetattr (shell_terminal, &shell_tmodes);
}
}

 

24.6.3 작업들을 개시하기

일단 쉘이 터미널을 제어하여서 작업제어를 수행하는 책임을 갖게 되면, 쉘은 사용자에의해 입력된 명령문에 응답하여 작업을 개시할 수 있다. 프로세스 그룹에서 프로세스들을 만들기 위해서는, 23.2절 [Process Creation Concepts] 에 설명된 fork 와 exec를 사용한다. 그곳에는 여러개의 자식 프로세스들이 이미 존재하고 있기 때문에, 그 일을 하기는 좀 많이 복잡하고 당신은 올바른 순서로 프로세스를 만들도록 주의를 해야만 한다. 그렇지 않다면, 고약한 경쟁상황(race condition)이 발생될 것이다.

당신은 프로세스들 사이의 부모-자식 관계를 어떻게 구성할것인지에 대해서 두가지를 선택할 수 있다. 프로세스 그룹안에 있는 모든 프로세스들을 쉘 프로세스의 자식 프로세스로 만들거나, 또는 그룹에 있는 한 개의 프로세스를 그 그룹에 있는 다른 모든 프로세스들의 조상이 되도록 만들수 있다. 이 장에 설명된 예제 쉘 프로그램은 첫 번째가 좀 간단하게 때문에 첫 번째를 사용한다.

만들어진 각각의 프로세스는, setpid를 호출하여 새로운 프로세스 그룹에 그 자신을 넣어야만 한다; 24.7.2절 [Process Group Functions] 참조. 새로운 그룹에 있는 첫 번째 프로세스는 그 프로세스 그룹의 리더가 되고 그 프로세스 ID가 그 그룹을 위한 프로세스 그룹 ID가 된다.

쉘은 새로운 프로세스 그룹으로 각각의 자식 프로세스들을 넣기 위해서 setpgid를 호출한다. 이것은 타이밍 문제가 내포되어 있다; 각각의 자식 프로세스는 새로운 프로그램이 실행되기 전에 프로세스 그룹에 들어가야만 하고, 쉘은 실행을 계속하기 전에 그룹이 가지고 있는 모든 자식 프로세스에 의존한다. 만일 자식 프로세스와 쉘이 모두 setpgid를 호출한다면, 이것은 프로세스가 먼저 그 일을 처리하도록 해서 아무런 문제가 발생되지 않을 것이다.

만일 전면 작업으로 어떤 작업이 진행되고 있다면, 새로운 프로세스 그룹을 tcsetpgrp를 사용해서 터미널을 제어하고 있는 전면으로 넣을 필요가 있다. 다시, 이것은 경쟁 상황을 피하기 위해서 각각의 자식 프로세스 뿐만아니라, 쉘에 의해서도 수행된다. 각 자식 프로세스의 다음 일은 시그널동작을 재설정하는 일이다.

초기화 하는동안, 쉘 프로세스는 작업제어 시그널들을 무시하도록 그 자신을 설정한다; 24.6.2절 [Initializing the Shell] 참조. 그 결과로, 그것이 만든 어떤 자식 프로세스도 또한 상속으로 인해서 그러한 시그널들을 무시하게 된다. 이것에 만족하지 못하면, 각각의 자식 프로세스는 그것이 만들어진 후에 SIG-DFL을 사용해서 그 시그널의 원래 동작으로 되돌려 설정할 수 있다.

쉘이 이러한 관습을 따르기 때문에, 응용 프로그램은 그들이 부모 프로세스로부터 시그널의 처리에 대한 것을 정확히 상속받는다고 가정 할 수 있다. 그러나 모든 응용프로그램은 멈춤 시그널들의 처리에 간섭할 수 없다. SUSP 문자의 일반적인 해석이 불가능하게 만든 응용프로그램은 사용자가 작업을 멈추게 하기 위해서 다른 메카니즘을 제공한다. 사용자가 이 메카니즘을 호출할 때, 그 프로그램은 단지 프로세스 그 자체가 아니라, 그 프로세스의 프로세스 그룹에게 SIGTSTP 시그널을 보낸다. 21.6.2절 [Signaling Another Process] 참조.

마침내, 각각의 자식 프로세스는 보통의 방법으로 exec를 호출하여야 한다. 이것은 표준 입/출력 채널들의 리다이렉션이 처리되는 지점이다. 8.8절 [Duplicating Descriptors] 를 참조하여 이것을 어떻게 하는지 보아라. 다음은 프로그램을 개시하기 위한, 대화식 쉘 프로그램에 있는 함수이다. 그 함수는 쉘에 의해서 자식 프로세스가 만들어진 후에 즉시 자식 프로세스에 의해서 실행되고 결코 리턴하지 않는다.

void
launch_process (process *p, pid_t pgid, int infile, int outfile, int errfile, int foreground)
{
pid_t pid;
if (shell_is_interactive)
{
/* 프로세스 그룹에 그 프로세스를 넣고 터미널을 프로세스 그룹에게 주어라, 적당하면, 이것은 쉘과 개별적인 자식 프로세스에 의해서 모두 실행되기 때문에 경쟁상황을 포함하고 있다. */
pid = getpid ();
if (pgid == 0) pgid = pid;
setpgid (pid, pgid);
if (foreground)
tcsetpgrp (shell_terminal, pgid);
/* 작업제어 시그널위한 처리를 디폴트로되돌려 설정하라. */
signal (SIGINT, SIG_DFL);
signal (SIGQUIT, SIG_DFL);
signal (SIGTSTP, SIG_DFL);
signal (SIGTTIN, SIG_DFL);
signal (SIGTTOU, SIG_DFL);
signal (SIGCHLD, SIG_DFL);
}
/* 새로운 프로세스를 위한 표준 입/출력 채널들을 설정하라. */
if (infile != STDIN_FILENO)
{
dup2 (infile, STDIN_FILENO);
close (infile);
}
if (outfile != STDOUT_FILENO)
{
dup2 (outfile, STDOUT_FILENO);
close (outfile);
}
if (errfile != STDERR_FILENO)
{
dup2 (errfile, STDERR_FILENO);
close (errfile);
}
/* 새로운 프로세스를 실행하라. exit를 확인하라. */
execvp (p->argv[0], p->argv);
perror ("execvp");
exit (1);
}

만일 쉘이 대화식으로 실행되지 않으면, 이 함수는 프로세스 그룹이나 시그널로 아무일도 하지 않는다. 작업제어를 수행하지 않는 쉘은 그 자체가 쉘인 프로세스 그룹안에 모든 서브프로세스들이 존재해야만 한다.

다음은 실제로 완전한 작업을 시작하는 함수이다. 자식 프로세스가 만들어진 후에, 이 함수는 전면이나 배경으로 새로이 만들어진 작업을 넣기위해서 어떤 다른 함수를 호출한다; 그것은 24.6.4절 [Foreground and Background] 에 설명되어 있다.

void
launch_job (job *j, int foreground)
{
process *p;
pid_t pid;
int mypipe[2], infile, outfile;
infile = j->stdin;
for (p = j->first_process; p; p = p->next)
{
/* 만일 필요하면 pipe들을 준비하라. */
if (p->next) {
if (pipe (mypipe) < 0) {
perror ("pipe");
exit (1);
}
outfile = mypipe[1];
} else {
outfile = j->stdout;
}
 
/* 자식 프로세스들을 만들어라 */
pid = fork ();
if (pid == 0) { /* 이것은 자식 프로세스이다. */
launch_process (p, j->pgid, infile, outfile, j->stderr, foreground);
} else if (pid < 0) {
/* fork 가 실패했다. */
perror ("fork");
exit (1);
} else { /* 이것은 부모 프로세스이다. */
p->pid = pid;
if (shell_is_interactive) {
if (!j->pgid)
j->pgid = pid;
setpgid (pid, j->pgid);
}
}
 
/* pipe들을 정리하라. */
if (infile != j->stdin)
close (infile);
if (outfile != j->stdout)
close (outfile);
infile = mypipe[0];
}
format_job_info (j, "launched");
if (!shell_is_interactive)
wait_for_job (j);
else if (foreground)
put_job_in_foreground (j, 0);
else
put_job_in_background (j, 0);
}

 

24.6.4 전면 과 배경

이제 전면(foreground)에 있는 작업을 시작할 때 쉘에 의해서 행해져야만 하는 동작은 무엇이며, 배경작업이 시작될 때 해야만 되는 것과 무엇이 어떻게 다른지 알아보자. 전면작업이 시작될 때, 쉘은 첫 번째로 tcsetpgrp를 호출해서 그 전면작업에 터미널 제어권을 줘야만 한다. 그리고나서, 쉘은 프로세스 그룹안에 있는 프로세스들이 종료되거나 멈출때까지 기다려야한다. 이것에 대한 상세한 내용은 24.6.5절 [Stopped and Terminated Jobs] 를 참조하라.

그룹안에 있는 모든 프로세스들이 수행됐거나 멈추었을 때, 쉘은 다시 tcsetpgrp를 호출해서 자신의 프로세스 그룹을 위해서 터미널 제어권을 되찾는다. 배경작업으로부터의 입/출력이나 사용자에의해 입력된 SUSP 문자가 원인이 된 멈춤 시그널이 프로세스 그룹에게 보내어지면, 보통, 작업안에 있는 모든 프로세스들이 함께 멈춘다.

전면작업이 터미널을 이상한 상황으로 만들었을지도 모르므로, 쉘은 계속하기전에 자신이 저장해놓았던 터미널 모드들을 반환하여야한다. 작업이 완전히 멈춘경우에, 쉘은 일단 현재 터미널 모드들을 저장하고, 그래서 만일 그 작업이 나중에 다시 계속된다면 그들을 반환할 수 있다. 터미널 모드들을 다루는 함수들은 tcgetattr 과 tcsetattr이 있다; 그들은 12.4절 [Terminal Modes] 를 참조하라. 다음은 위에 설명된 일들을 하는 예제 쉘을 함수이다.

/* 작업 j를 전면에 놓는다. 만일 cont가 0이 아니면, 저장된 터미널 모드들을 반환하고 우리가 블록하기 전에 그것이 계속되도록 SIGCONT 시그널을 프로세스 그룹에게 보낸다. */
void
put_job_in_foreground (job *j, int cont)
{
/* 전면으로 작업을 놓는다. */
tcsetpgrp (shell_terminal, j->pgid);
/* 만일 필요하다면 작업을 계속하도록 시그널을 보낸다. */
if (cont) {
tcsetattr (shell_terminal, TCSADRAIN, &j->tmodes);
if (kill (- j->pgid, SIGCONT) < 0)
perror ("kill (SIGCONT)");
}
/* 보고하도록 기다린다. */
wait_for_job (j);
/* 전면에 쉘을 다시 놓아라. */
tcsetpgrp (shell_terminal, shell_pgid);
/* 쉘의 터미널 모드들을 반환한다. */
tcgetattr (shell_terminal, &j->tmodes);
tcsetattr (shell_terminal, TCSADRAIN, &shell_tmodes);
}
만일 프로세스 그룹이 배경작업으로써 시작된다면, 쉘은 전면에 자신을 놓고 터미널로부터 명령문 읽기를 계속한다. 예제 쉘에서는, 배경에 작업을 놓아야 될 필요가 그다지 없다. 다음은 그것을 사용하는 함수이다.
/* 배경에 작업을 놓는다. 만일 cont 인수가 참이면, 그것이 계속되도록 SIGCONT 시그널을 프로세스 그룹에게 보낸다. */
void
put_job_in_background (job *j, int cont)
{
/* 만일 필요하면, 작업을 계속하도록 시그널을 보낸다. */
if (cont)
if (kill (-j->pgid, SIGCONT) < 0)
perror ("kill (SIGCONT)");
}

 

24.6.5 멈추고 종료된 작업들

전면 프로세스가 시작될 때, 쉘은 작업에 있는 모든 프로세스들이 멈추거나 종료될때까지 블록해야만 한다. 그것은 waitpid 함수를 호출함으로써 이루어진다; 23.6절 [Process Completion] 참조. 프로세스가 종료된것뿐만 아니라 멈춤 또한 보고하도록 WUNTRACED 옵션을 사용하라. 쉘은 배경작업이 멈추었거나 종료된 작업들을 사용자에게 보고하도록 배경작업들의 상황을 체크해야만 한다; 이것은 WNOHANG 옵션을 사용해서 waitpid 함수를 호출함으로써할 수 있다. 작업이 멈추었거나 종료되었음을 체크하는것과 같은 코드문을 넣는 좋은 위치는 새로운 명령문을 읽으려(prompting) 하기 전이다.

쉘은 SIGCHLD 시그널을 처리하는 핸들러를 만듦으로써 자식 프로세스를 위한 유용한 상황정보를 비동기적으로 통지받을 수 있다. 21장 [Signal Handling] 참조.

예제 쉘 프로그램의 경우에는, SIGCHLD 시그널은 보통 무시된다. 쉘이 조작하고 있는 전역 데이터 구조체를 재진입하는 문제를 피하기 위함이다. 그러나 쉘이 그들 데이터 구조체를 사용하지 않는 어떤 시간동안에는 _예를들어, 터미널에서 입력을 기다리는 때와 같은_SIGCHLD 시그널을 처리하는 핸들러는 가능하다. 동기적으로 상황들을 체크하는데 사용되는 같은 함수는 (이 경우, do_job_notification) 이 핸들러로부터 호출될 수 있다.

다음은 작업의 상황들을 체크하고 사용자에게 정보를 보고하는 것을 취급하는 예제 쉘 프로그램의 일부분이다.

/* waitpid에 의해 리턴된 프로세스 pid의 상황을 저장하라. 모두 잘 됐으면 0을 리턴하고, 아니면 0이 아닌값을 리턴하라. */
int
mark_process_status (pid_t pid, int status)
{
job *j;
process *p;
if (pid > 0) {
/* 프로세스를 위해서 기록을 갱신하라. */
for (j = first_job; j; j = j->next) {
for (p = j->first_process; p; p = p->next) {
if (p->pid == pid) {
p->status = status;
if (WIFSTOPPED (status)) {
p->stopped = 1;
} else {
p->completed = 1;
if (WIFSIGNALED (status))
fprintf(stderr, "%d: Terminated by signal %d.\n", (int)pid, WTERMSIG(p->status));
}
return 0;
}
fprintf (stderr, "No child process %d.\n", pid);
return -1;
} /* for 의 끝 */
} /* for 의 끝 */
} else if (pid == 0 || errno == ECHILD) {
/* 보고하기위해 준비된 프로세스가 없다. */
return -1;
} else { /* Other weird errors. */
perror ("waitpid");
return -1;
}
}
/* 블록하지지 않고, 유용한 상황정보를 가진 프로세스들을 체크하라. */
void
update_status (void)
{
int status;
pid_t pid;
do {
pid = waitpid(WAIT_ANY, &status, WUNTRACED|WNOHANG);
} while (!mark_process_status (pid, status));
}
/* 주어진 작업안에 있는 모든 프로세스들이 보고되었을때까지 블록하여, 유용한 상황정보를 가진 프로세스들을 체크하라. */
void
wait_for_job (job *j)
{
int status;
pid_t pid;
do {
pid = waitpid (WAIT_ANY, &status, WUNTRACED);
} while (((!mark_process_status (pid, status))
&& (!job_is_stopped (j))
&& (!job_is_completed (j)));
}
/* 사용자에게 보이기위한 작업상황에 대한 정보를 형식화하라. */
void
format_job_info (job *j, const char *status)
{
fprintf(stderr, "%ld (%s): %s\n", (long)j->pgid, status, j->command);
}
/* 멈추었거나 종료된 작업들에 대해서 사용자에게 보고하라. 활성화된 작업 리스트로부터 종료된 작업들을 지워라. */
void
do_job_notification (void)
{
job *j, *jlast, *jnext;
process *p;
/* 자식 프로세스를 위한 상황정보들을 갱신하라. */
update_status ();
jlast = NULL;
for (j = first_job; j; j = jnext)
{
jnext = j->next;
/* 만일 모든 프로세스들이 완수되었다면, 작업들이 완수되었음을 사용자에게 알리고 활성 작업 리스트에서 그것을 지워라. */
if (job_is_completed (j)) {
format_job_info (j, "completed");
if (jlast)
jlast->next = jnext;
else
first_job = jnext;
free_job (j);
} else if (job_is_stopped (j) && !j->notified) {
/* 더 이상 진행할 수 없음을 표시하여, 멈추어진 작업에 대하여 사용자에게 통지하라. */
format_job_info (j, "stopped");
j->notified = 1;
jlast = j;
} else /* 여전히 실행되고 있는 작업들에 대해서는 아무것도 말하지 말아라. */
jlast = j;
}
}

 

24.6.6 멈추어있는 작업들을계속 실행시키기

쉘은 프로세스 그룹에게 SIGCONT 시그널을 보냄으로써 멈추어진 작업을 계속하게 할 수 있다. 만일 작업이 전면에서 계속 실행되어야하면, 쉘은 일단 tcsetpgrp 를 호출해서 터미널 제어권을 그 작업에게 부여하고, 저장된 터미널 설정을 반환한다. 전면에서 작업이 재개된 후에, 쉘은 그 작업이 마치 전면에서 시작된것처럼, 그 작업이 멈추거나 종료되기를 기다린다.

예제 쉘 프로그램에서 새로이 만들어진 작업과 재개된 작업들에 대한 처리는 put_job_in_foreground 와 put_job_in_background 한쌍의 함수로 이루어진다. 그들 함수에 대한 정의는 24.6.4절 [Foreground and Background] 에 나와있다. 멈추었던 작업을 재개할 때, cont 인수에 주어진 0이 아닌값은 SIGCONT 시그널을 보내고 적당한 터미널 모드를 반환함을 확실하게 한다.

다음은 재개되어 실행되고 있는 작업에 대해서 쉘이 내부적으로 보유하고 있던 정보를 갱신하는 함수이다.

/* 멈추어있던 작업 J를 다시 실행되고 있는 작업으로써 표시하라. */
void
mark_job_as_running (job *j)
{
Process *p;
for (p = j->first_process; p; p = p->next)
p->stopped = 0;
j->notified = 0;
}
/* 작업 J를 계속하라. */
void
continue_job (job *j, int foreground)
{
mark_job_as_running (j);
if (foreground)
put_job_in_foreground (j, 1);
else
put_job_in_background (j, 1);
}

 

24.6.7 이 장에서 설명되지 않은 부분들

이장에 포함된 예제 쉘을 위한 여분의 코드는 전체 쉘 프로그램을 위한 일부분이다. 하지만, 어떻게 작업과 프로그램 데이터 구조체들이 할당되고 초기화되는지에 대해서는 전혀 얘기하지 않았다. 대부분의 실제 쉘은 명령문; 변수들; 약어, 대입, 그리고 파일이름의 패턴 매칭등을 위한 것을 제공하는, 복잡한 사용자 인터페이스로 되어있다. 이곳에 설명된 이 모든 것은 복잡함과는 거리가 멀다! 대신에, 우리는 어떻게 코아 프로세스를 생성을 하는지를 보여주고 그와 같은 쉘에서 어떤 작업제어 함수들이 호출될 수 있는지에 대해서 관심을 두었다. 다음은 우리가 표현했던 주요 엔트리 포인트를 요약한 테이블이다.

void init_shell (void)

쉘의 내부 상황을 초기화한다. 24.6.2절 [Initializing the Shell] 참조.

void init_sh

void launch_job (job *j, int foreground)

전면 또는 배경에서 작업 j를 시작한다. 24.6.3절 [Launching Jobs] 참조.

void do_job_notification (void)

종료되거나 멈추어진 어떤 작업들이 있는지 체크하고 보고한다. SIGCHLD 시그널을 위한 핸들러 안에서 또는 동기적으로 호출될 수 있다. 24.6.5절 [Stopped and Terminated Jobs] 참조.

void continue_job (job *j, int foreground)

작업 j를 재개한다. 24.6.6절 [Continuing Stopped Jobs] 참조.
물론, 실제 쉘은 작업을 처리하기 위해서 다른 함수들을 제공받기 원할지 모른다. 예를들어, 활성화된 모든 작업들의 리스트를 보여주거나, 작업에게 시그널(SIGKILL 과 같은)을 보내는 명령문은 유용할 것이다.

24.7 작업제어를 위한 함수들

이 절은 작업제어와 연관된 함수들을 자세하게 설명하고 있다.

 

24.7.1 제어중인 터미널 확인하기

당신은 제어중인 터미널을 개방하기 위해서 사용할 수 있는 파일이름을 얻기 위해서 ctermid 함수를 사용할 수 있다. GNU 라이브러리에서는, 항상 같은 문자열이 리턴된다: "/dev/tty". 그것은 현재 프로세스의 제어 중인 터미널(만일 그것이 한 개라면)을 참조하기위한 "이상한" 특별파일 이름이다. ctermid 함수는 헤더파일 `stdio.h'에 선언되어 있다.

함수 : char * ctermid (char *string)

ctermid 함수는 현재 프로세스를 위해서 제어중인 터미널의 파일이름이 포함된 문자열을 리턴한다. 만일 문자열이 널 포인터가 아니라면, 그것은 적어도 L_ctermid 문자들을 저장하고 있는 배열이 될 것이다. 문자열을 이 배열안에 리턴된다. 그렇지 않다면, 정적 지역안에 리턴된 문자열에 대한 포인터는 이 함수가 연속적으로 호출되어 덧씌워질 것이다.
만일 어떠한 이유로 파일이름이 결정될 수 없다면 빈 문자열(empty string)을 리턴한다. 심지어 파일이름이 리턴됐을지라도, 그 파일에 대한 억세스는 보증되지 않는다.

매크로 : int L_ctermid

이 매크로는 ctermid에 의해 리턴된 파일이름을 저장하기에 충분히 큰 문자열의 크기를 나타내는 정수 상수 표현식이다.

또한 12.1절 [Is It a Terminal] 에 있는 isatty 와 ttyname 함수를 참조하라.

 

24.7.2 프로세스 그룹 함수들

다음은 프로세스 그룹을 다루기 위한 함수를 설명하고 있다. 당신의 프로그램에서 그들 함수들을 사용하기 위해서는 헤더파일 `sys/types.h' 와 `unistd.h'를 포함해야만 한다.

함수 : pid_t setsid (void)

setsid 함수는 새로운 세션을 만든다. 호출한 프로세스는 세션리더가 되고, 그 프로세스의 프로세스 ID와 같은 ID를 가진 새로운 프로세스 그룹이 만들어지고 프로세스가 그 안에 소속된다. 새로운 프로세스 그룹에 다른 프로세스들이 없고 새로운 세션안에 다른 프로세스 그룹이 없이 초기화된다. 이 함수는 또한 호출한 프로세스가 제어중인 터미널을 갖지 않도록 만든다.
setsid 함수는 만일 성공하면 호출한 프로세스의 새로운 프로세스 그룹 ID를 리턴하고 실패하면 -1의 값을 리턴한다.  
다음은 이 함수를 위해 정의된 에러상황이다.

    EPERM

    호출한 프로세스가 이미 프로세스 그룹의 리더이거나, 같은 프로세스 그룹 ID를 가진 다른 프로세스 그룹이 있다.
getpgrp 함수는 두 개의 정의를 가진다; 한 개는 BSD 유닉스에서 왔고, 한 개는 POSIX.1 표준으로부터 온 것이다. 당신이 선택한 테스트 매크로(1.3.4절 [Feature Test Macros] 참조.)에 따라서 당신이 어떤 정의를 선택했는지가 결정된다. 즉, 당신이 _BSD_SOURCE를 정의하면 BSD 것이 선택되고; 그렇지않고, _POSIX_SOURCE 또는 _GNU_SOURCE를 정의한다면 POSIX의 것이 선택된 것이다. 오래된 BSD 시스템에서 만들어진 프로그램들은 _BSD_SOURCE 하에서 특별히 정의된 getgrp를 사용하도록 `unistd.h'를 인클루드 할 수없다. 당신은 BSD정의를 획득 하기 위해서 -lbsd-compact 로 그와 같은 프로그램들을 링크해야만 한다.

    POSIX.1 함수 : pid_t getpgrp (void)

    getpgrp의 POSIX.1 정의는 호출한 프로세스의 프로세스 그룹 ID를 리턴한다.

    BSD 함수 : pid_t getpgrp (pid_t pid)

    getpgrp 의 BSD 정의는 프로세스 pid의 프로세스 그룹 ID를 리턴한다. 당신이 호출한 프로세스에 대한 정보를 얻기위해서는 pid인수를 위해서 0의 값을 사용할 수 있다.

함수 : int setpgid (pid_t pid, pid_t pgid)

setpgid 함수는 프로세스 그룹 pgid에 프로세스 pid를 소속시킨다. 특별한 경우로, pid 또는 pgid는 호출한 프로세스의 프로세스 그룹을 지적하기 위해서 0으로 될 수 있다. 이 함수는 작업제어를 지원하지 않는 시스템에서는 실패한다. 24.2절 [Job Control is Optional] 참조하여 상세한 정보를 얻어라.
만일 명령이 성공하면, setpgid는 0을 리턴한다. 그렇지 않다면 -1을 리턴한다.  
다음의 errno는 이 함수를 위해 정의된 에러상황이다.

EACCES : pid라는 이름을 가진 자식 프로세스가 만들어진 후에 exec 함수를 통해서 실행되었다.

EINVAL : pgid의 값이 유용하지 않다.

ENOSYS : 시스템이 작업제어를 지원하지 않는다.

EPERM

pid 인수에 의해 지적된 프로세스가 세션리더이거나, 호출한 프로세스와 같은 세션에 없거나, pgid 인수의 값이 호출한 프로세스와 같은 세션안에 있는 프로세스 그룹 ID와 매치되는 것이 없다.

ESRCH

pid 인수에 의해 지적된 프로세스가 호출한 프로세스가 아니거나 호출한 프로세스의 자식 프로세스가 아니다.

함수 : int setpgrp(pid_t pid, pid_t pgid)

이것은 setpgid를 위한 BSD용이다. 두 함수는 같은 일을 한다.

 

24.7.3 제어권을 가진 터미널을 억세스하기 위한 함수들

다음은 터미널의 전면프로세스 그룹을 알아내거나 설정하기 위한 함수들이다. 당신은 그들 함수들을 당신의 어플리케이션에서 사용하기 위해서는 헤더파일 `sys/types.h'와 `unistd.h'를 인클루드해야만 한다. 그들 함수들이 터미널 디바이스를 정하도록 파일 기술자 인수를 정한다고 하더라도, 전면작업은 터미널 파일 그자체와 연관되어 있고 특별히 개방된 파일 기술자가 아니다.

함수 : pid_t tcgetpgrp(int filedes)

이 함수는 기술자 filedes로 개방한 터미널과 연관된 전면 프로세스 그룹의 프로세스 그룹 ID를 리턴한다. 만일 아무런 전면 프로세스 그룹이 없다면, 현존하는 프로세스 그룹의 프로세스 그룹 ID와 매치 되지 않는, 1보다 큰 수를 리턴한다. 그러한 경우는 전면작업으로써 수행되고 있던 작업안에 있는 모든 프로세스들이 종료되고 전면으로 옮겨질 작업들이 없을 때 발생할 수 있다
에러의 경우에 -1의 값이 리턴된다. 다음의 errno는 이 함수를 위해 정의된 에러상황이다.

EBADF : filedes 인수가 유용한 파일 기술자가 아니다.

ENOSYS : 시스템이 작업제어를 지원하지 않는다.

ENOTTY : filedes 인수와 연관된 터미널 파일이 호출한 프로세스가 제어중인 터미널이 아니다.

함수 : tcsetpgrp(int filedes, pid_t pgid)

이 함수는 터미널의 전면 프로세스 그룹 ID를 설정하는데 사용된다. 인수 filedes는 터미널을 지정하는 기술자이다; pgid 인수는 프로세스 그룹을 지정한다. 호출한 프로세스는 pgid와 같은 세션의 멤버가 되어야만 하고 같은 터미널을 제어하고 있어야만 한다.
터미널 억세스를 목적으로 하여, 이 함수는 출력으로 취급된다. 만일 배경 프로세스로부터 이 함수가 호출된다면, 보통 그 프로세스 그룹안에 있는 모든 프로세스들에게 SIGTTOU 시그널이 보내어진다. 만일 호출한 프로세스 자체가 SIGTTOU 시그널을 무시하는 예외의 경우라면, 그 명령은 수행되고 아무런 시그널도 보내어지지 않는다.
만일 성공하면, tcsetpgrp 는 0을 리턴한다. 에러가 발생한 경우에는 -1을 리턴한다.
다음의 errno는 이 함수를 위해 정의된 에러상황이다.

EBADF : filedes 인수가 유용한 파일 기술자가 아니다.

EINVAL : pgid 인수가 유용하지 않다.

ENOSYS : 시스템이 작업제어를 지원하지 않는다.

ENOTTY : filedes는 호출한 프로세스가 제어하고 있는 터미널이 아니다.

EPERM : pgid 는 호출한 프로세스와 같은 세션에 있는 프로세스 그룹이 아니다.

이 게시물을...