Selain masalah "terlalu banyak sinyal", sinyal dapat diabaikan secara eksplisit. Dari man 2 signal :
If the signal signum is delivered to the process, then one of the
following happens:
* If the disposition is set to SIG_IGN, then the signal is ignored.
Sinyal juga bisa diblokir. Dari man 7 signal;
A signal may be blocked, which means that it will not be delivered
until it is later unblocked. Between the time when it is generated
and when it is delivered a signal is said to be pending.
Kumpulan sinyal yang diblokir dan diabaikan diwariskan oleh proses turunan, jadi mungkin saja proses induk aplikasi Anda mengabaikan atau memblokir salah satu dari sinyal ini.
Apa yang terjadi ketika banyak sinyal dikirim sebelum proses selesai menangani yang sebelumnya? Itu tergantung pada OS. signal(2) halaman manual yang ditautkan di atas membahasnya:
- Sistem V akan mengatur ulang disposisi sinyal ke default. Lebih buruk lagi, pengiriman beberapa sinyal secara cepat akan menghasilkan panggilan rekursif (?).
- BSD akan secara otomatis memblokir sinyal hingga penangan selesai.
- Di Linux, ini bergantung pada flag kompilasi yang disetel untuk GNU
libc, tapi saya mengharapkan perilaku BSD.
Anda tidak dapat percaya bahwa setiap sinyal yang dikirim akan terkirim. Misalnya, kernel linux "menggabungkan" SIGCHLD jika suatu proses membutuhkan waktu lama dalam menangani SIGCHLD dari proses anak yang keluar.
Untuk menjawab bagian lain dari pertanyaan Anda, sinyal akan "diantrekan" di dalam kernel jika sejumlah sinyal berbeda tiba dalam interval yang terlalu pendek.
Anda harus menggunakan sigaction() untuk mengatur penangan sinyal dengan sa_sigaction anggota siginfo_t , menyetel sa_mask anggota siginfo_t argumen dengan hati-hati. Saya pikir ini berarti menutupi semua sinyal "asynch" setidaknya. Menurut halaman manual untuk Linux sigaction() , Anda juga akan menutupi sinyal yang sedang ditangani. Saya pikir Anda harus mengatur sa_flags anggota ke SA_SIGINFO, tetapi saya tidak ingat mengapa saya memiliki takhayul ini. Saya percaya ini akan membuat proses Anda menjadi penangan sinyal yang tetap disetel tanpa kondisi balapan, dan yang tidak terganggu oleh sebagian besar sinyal lainnya.
Tulis fungsi penangan sinyal Anda dengan sangat hati-hati. Pada dasarnya cukup atur variabel global untuk menunjukkan bahwa sinyal tertangkap, dan proses selanjutnya berurusan dengan tindakan yang diinginkan untuk sinyal itu. Sinyal akan disamarkan untuk waktu yang paling sedikit dengan cara itu.
Juga, Anda ingin menguji kode penanganan sinyal Anda dengan sangat teliti. Masukkan ke dalam proses pengujian kecil dan kirim sinyal SIGUSR1 dan SIGUSR2 sebanyak mungkin, mungkin dari 2 atau 3 program pengiriman sinyal tujuan khusus. Campurkan beberapa sinyal lain juga, setelah Anda yakin bahwa kode Anda dapat menangani SIGUSR1 dan SIGUSR2 dengan cepat dan benar. Persiapkan diri Anda untuk proses debug yang sulit.
Jika Anda menggunakan linux dan hanya linux, Anda mungkin berpikir untuk menggunakan signalfd() untuk membuat deskriptor file yang dapat Anda select() atau jajak pendapat untuk menerima sinyal tersebut. Menggunakan signalfd() mungkin membuat proses debug lebih mudah.
Sinyal dijamin terkirim, dalam artian jika suatu proses berhasil memanggil kill , maka target akan menerima sinyal. Ini asinkron:pengirim tidak memiliki cara untuk mengetahui kapan sinyal diterima atau diproses. Namun, ini tidak menjamin bahwa sinyal akan terkirim. Target bisa mati sebelum dapat memproses sinyal. Jika target mengabaikan sinyal pada saat dikirim, sinyal tidak akan berpengaruh. Jika target menerima beberapa contoh dari nomor sinyal yang sama sebelum dapat memprosesnya, sinyal dapat (dan biasanya) digabungkan:jika Anda mengirim sinyal yang sama dua kali ke suatu proses, Anda tidak dapat mengetahui apakah proses tersebut akan menerima sinyal. sekali atau dua kali. Sinyal sebagian besar dirancang untuk mematikan proses atau sebagai cara untuk membuat proses memperhatikan, sinyal tidak dirancang untuk komunikasi seperti itu.
Jika Anda membutuhkan pengiriman yang andal maka Anda memerlukan mekanisme komunikasi yang berbeda. Ada dua mekanisme komunikasi utama antar proses:sebuah pipa memungkinkan komunikasi searah; soket memungkinkan komunikasi dua arah dan banyak koneksi ke server yang sama. Jika Anda membutuhkan target untuk memproses notifikasi sebanyak yang Anda kirim, kirimkan byte melalui pipa.