동기 신호 처리

비동기 신호 처리와 비교하여 동기 신호 처리 (SIGSEGV, SIGILL 등)에 대한 리소스를 찾으려고합니다.동기 신호 처리

일반적인 신호 처리 메커니즘 (예 : kill 사용)은 커널에서 사용자 모드로의 제어 전송시 신호 처리기를 호출합니다. 동기 신호는 일반적으로 CPU 인터럽트 (메모리 보호 등)와 관련되어 있고 커널 처리기가 호출되기 때문에 '동기식'신호가 시스템 호출과 유사하게 작동합니다.

동기 신호 핸들러에서 'async-signal-unsafe'안전성이있는 libc 기능이 있습니까? 예를 들어 리눅스 mprotect (2) 매뉴얼 페이지가 SIGSEGV 핸들러 내에서 printf를 사용하는 것을 볼 수 있습니다. 이러한 상황에서 기능을 사용할 수 있는지 어떻게 결정할 수 있습니까?
일반적인 유닉스 계열 커널의 동기 신호 처리 방식은 비동기 신호 처리 방식과 어떻게 다릅니 까? 무엇이 그들을 '동기식'으로 만드는가?

출처

2017-09-05 Shrikant Giridhar

신호가 비동기식으로 정의되지 않았습니까? –

잘 모르겠습니다. 이것은 두 가지 유형이 있다고 말합니다 : ftp://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_24.html. –

더 동기가 없습니다 및 비동기 신호이지만, 일부 신호는 비동기 적으로 전달되고 다른 신호는 동기 또는 비동기로 전달 될 수 있습니다.

배달은 항상 동일합니다. 설정된 경우 사용자 모드의 신호 처리기가 호출됩니다. 설정되지 않은 경우 기본 동작이 사용됩니다 (기본 동작은 무시하거나 일시 중지 한 일부 신호를 제외하고 프로세스를 종료하는 것입니다).

신호가 외부 원인 (예 : kill)에 의해 시작되면 신호가 비동기 적으로 전달 된 것으로 간주됩니다. 이러한 경우 프로세스의 관점에서 보면 방출과 전달 사이에 시간이 있습니다. 프로세스는 많은 것을 실행할 수 있습니다 ...

신호가 있어야하는 내부 런타임 원인이 감지되면 신호가 동 기적으로 전달됩니다 방출. 예를 들어, SIGSEGV 또는 SIGBUS을 전달할 수있는 잘못된 메모리 액세스, 0으로 나누기와 같은 부동 소수점 오류 (SIGFPE을 전달하는), 잘못된 명령어 (SIGILL) 등을 전달할 수있는 잘못된 메모리 액세스가 있습니다. 이러한 경우에는 현재 실행 된 코드/명령어 인 오류의 원인이되면 신호가 즉시 방출 된 다음 전달됩니다. 이 경우 프로세스의 관점에서 보면 방출과 전달 사이에는 아무런 변화가 없습니다.

출처

2017-09-05 12:49:14

동기 대 비동기 전달은 프로그램의 비동기 신호 안전성에 어떤 영향을 줍니까? Linux의'man mprotect (2)'에있는 프로그램을 생각해보십시오. 처리기가 비동기 신호가 안전하지 않은 함수를 사용할 때 올바르지 않습니까? –

예 ** 신호 발생이 동기인지 여부를 알 수 없기 때문에 ** 모든 ** 신호 처리기에서 async-signal-unsafe 함수를 사용하는 것은 올바르지 않습니다. (1) 일부 외부 이벤트가 SIGFPE를 생성 할 수 있으므로 프로세스가 동기인지 여부를 알 수 없습니다 (2) 동기 전달 발생시 비동기 안전하지 않은 기능 호출이 허용되는지 여부를 알 수 없습니다. 그래서 ** 신호 처리기 **에서 비동기 신호 기능을 호출하지 마십시오. –

내가 최고의 자원 중 하나가 거기에서 생각 :

The Linux Programming interface by Michael KerrisK 장 20, 21, 22
Linux System Programming by Robert Love 제 9 장

출처

2017-09-05 12:48:55 Guillermo

여기에는 두 부분이 있습니다. 신호의 생성과 신호의 수신. 신호 처리기를 통해 신호가 프로그램에 수신됩니다. 신호 처리기와 관련하여 신호 수신은 항상 비동기 적입니다 (즉, 신호 수신 시점을 예측할 수 없습니다).

신호 생성이 동기식인지 비동기식인지는 또 다른 질문입니다. 외부 장치로부터의 인터럽트는 분명히 비동기입니다. 프로그램에서 신호를 발생시키는 호출은 호출이 반환 될 때까지 해당 프로그램을 차단합니다. 호출 중에 신호는 비동기 적으로 (즉, 수신 프로그램을위한 대기열에 놓이게) 또는 동기식으로시그널링 된 프로그램의 핸들러가 호출되고 시그널링 프로그램/쓰레드는 핸들러가 리턴 할 때까지 일시 중단되며, 아마도 어떤 값을 리턴 할 수 있습니다.) 예는 Windows SendMessage (동기) 및 PostMessage (비동기)입니다.

추가 : "인터럽트 외부 장치에서 명확하게 비동기 "및 처리기가 끝날 때까지 현재 실행중인 프로세스를 일시 중단. 따라서 세그먼테이션 위반 인 하드웨어 인터럽트는 현재 실행중인 프로세스 (하드웨어 신호를 생성 함)를 일시 중단합니다. 기본 처리는 프로세스를 종료하는 것입니다.

출처

2017-09-05 12:58:15

예를 들어 현재 프로세스가 SIGSEGV에서 일시 중지 된 경우 안전하지 않은 함수 즉 printf가 안전합니까? 일시 중지 된 경우에도 현재 프로세스가 잠금을 유지하지 않을까요? –

printf에 대한 호출이 허용되지 않습니다 (적어도 동작은 정의되지 않았습니다). 시그널 전달은 시그널 관리 (시그널 마스크 등)를 제외하고는 전역적인 프로세스 상태에는 아무런 영향을 미치지 않습니다. 잠긴 자물쇠는 잠겨있어 ... –

신호 처리 앞서 언급 한 것처럼 동기식 및 비동기식입니다. 동기식이란 일부 명령을 실행하는 프로세스/스레드를 의미하며이 실행으로 인해 인터럽트가 발생했습니다. forex int * a; printf ("% d", * a); 세그먼트 오류가 발생할 수 있습니다. 비동기 : -client 프로세스 및 서버 프로세스 예제 : -server가 중지되면 클라이언트가 중지 할 신호를 보냅니다. 클라이언트가 외부 프로세스에서 발생하는 인터럽트를 생성하지 않습니다. 프로세스에 문제가있는 동기식 인터럽트가있을 때마다 해결합니다. 가능한 한 최소한의 라이브러리 나 복잡한 명령문을 처리하지 않는 것이 좋습니다. 일부 라이브러리 함수가 다시 사용되는 경우보다 인터럽트가 발생합니다. 더 좋은 방법은 신호 처리기 자체에서 자동 프로세스 재시작을하는 것입니다.

출처

2017-09-05 13:49:59 Rohit

답변

관련 문제