`Kill -l` neden 32 ve 33 sinyal numaralarını listelemiyor?


18

Yürütme kill -llinux üzerinde verir:

 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

Ne oldu 32ve 33? Neden listede yok? Ortada 2 atlamak yerine 1'de başlayıp 62'de bitebilirler mi?


PS "Hata kodları" yoktur - bunlar sinyal numaralarıdır.
G-Man, 'Monica'yı Eski

Yanıtlar:


20

Çünkü taşımaktadır NPTL . GNU C kütüphanesinin bir parçası olduğu için hemen hemen her modern linux dağıtımı artık ilk iki gerçek zamanlı sinyali kullanmıyor. NPTL, POSIX İş Parçacıklarının bir uygulamasıdır . NPTL, ilk iki gerçek zamanlı sinyali dahili olarak kullanır.

Sinyal kılavuzunun bu kısmı çok ilginç:

Linux çekirdeği, 33 ila 64 numaralı 32 farklı gerçek zamanlı sinyali destekler. Ancak, glibc POSIX iş parçacığı uygulaması dahili olarak iki (NPTL için) veya üç (LinuxThreads için) gerçek zamanlı sinyal kullanır (pthreads (7)) ve SIGRTMIN değerini uygun şekilde ayarlar (34 veya 35'e). Kullanılabilir gerçek zamanlı sinyal aralığı glibc iş parçacığı uygulamasına göre değiştiğinden (ve bu varyasyon çalışma zamanında mevcut çekirdeğe ve glibc'ye göre oluşabilir) ve gerçekten de gerçek zamanlı sinyal aralığı UNIX sistemlerinde farklılık gösterebilir asla sabit kodlu sayılar kullanan gerçek zamanlı sinyallere başvurmaz, bunun yerine her zaman SIGRTMIN + n gösterimini kullanarak gerçek zamanlı sinyallere başvurmalı ve SIGRTMIN + n'nin SIGRTMAX'ı aşmadığı uygun (çalışma zamanı) kontrolleri içermelidir.

Ayrıca glibc kaynak kodunu kontrol ettim; bakınız satır 22 . __SIGRTMIN+2 artırıldığından, ilk iki gerçek zamanlı sinyal gerçek zamanlı sinyal aralığının dışında tutulur.


Peki nasıl bir yok olsun kod yürütme bir parça çalışma zamanında SIGRTMIN mevcut değerini?
SlySven

10

Çünkü sinyaller:

SIGWAITING 32 Ignore All LWPs blocked 
    SIGLWP 33 Ignore Virtual Interprocessor Interrupt for Threads Library 

İkisi de Linux'ta desteklenmiyor. (LWP, LightWeight Süreci anlamına gelir )

Kaynak: IBM DeveloperWorks Solaris - Linux Bağlantı Kılavuzu


Linux'un 32 ve 33 numaralı sinyalleri vardı. Bkz . Unixhelp.ed.ac.uk/CGI/man-cgi?signal+7 , Real-time Signalsbölüm.
cuonglm

@Gnouc - kill -l RTMINbaşvurulan belgeye göre 32 değil, 34'te başlar. Bu , 33'te başladığını söylüyor, ancak sayılar glibc iş parçacığı uygulamasına bağlı olarak değişebileceğinden sayılara başvurmamanız gerektiğini söylüyor.
14:58

Elbette sisteme göre değişir, ancak Linux'un desteklemediği terim yanlıştır. Şuna başvurabilirsiniz: cse.psu.edu/~dheller/cmpsc311/Lectures/Process-Control-Signals/… . Belki de 32, 33 sinyaliyle neler olduğunu bize bildirmek için uzun zaman önce Linux ile çalışan bir vererana ihtiyacımız var. Neden belgelenmiyorlar.
cuonglm

RT pthread kütüphanesi tarafından dahili olarak kullanılırlar ve geçmişte üç değil iki olurdu, çünkü farklı bir sistem bunu içsel amaçlar için kullandı. Bir kodlama bakış açısından, SIGSYS üzerindeki sinyaller için derleme zamanı sabitleri kullanmanız gerekmez, örn. SIGRTMINBir #defineçizgi içeren bir küme, çünkü bu sayı çalıştırılabilir çalıştırıldığında daha sonra olası değişikliğe tabidir. Bu, birkaç yıl önce, bir pthread kütüphanesine karşı derlenmiş bir uygulama diğeriyle yeniden başlatılan bir sistemde çalıştırıldıysa, her iki pthread kütüphanesinin de kullanıldığı zaman ortaya çıkacaktı!
SlySven
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.