Tại sao `kill -l` không liệt kê các số tín hiệu của 32 và 33?


18

Thực thi kill -ltrên linux cho:

 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

Điều gì đã xảy ra 3233? Tại sao nó không được liệt kê? Họ có thể đã bắt đầu từ 1 và kết thúc ở 62 thay vì bỏ qua 2 ở giữa?


PS Không có "mã lỗi" - chúng là số tín hiệu.
G-Man nói 'Phục hồi Monica'

Câu trả lời:


20

Đó là vì NPTL . Vì nó là một phần của thư viện GNU C, gần như mọi bản phân phối linux hiện đại không sử dụng hai tín hiệu thời gian thực đầu tiên nữa. NPTL là một triển khai của Chủ đề POSIX . NPTL sử dụng nội bộ của hai tín hiệu thời gian thực đầu tiên.

Phần này của trang tín hiệu rất thú vị:

Hạt nhân Linux hỗ trợ một phạm vi 32 tín hiệu thời gian thực khác nhau, được đánh số từ 33 đến 64. Tuy nhiên, việc triển khai các luồng POSIX của glibc sử dụng hai tín hiệu thời gian thực (cho NPTL) hoặc ba (đối với LinuxThreads) (xem pthreads (7)) và điều chỉnh giá trị của SIGRTMIN một cách phù hợp (đến 34 hoặc 35). Do phạm vi của các tín hiệu thời gian thực khả dụng khác nhau tùy theo triển khai luồng glibc (và biến thể này có thể xảy ra vào thời gian chạy theo kernel và glibc có sẵn), và thực tế, phạm vi tín hiệu thời gian thực khác nhau giữa các hệ thống UNIX, các chương trình nên không bao giờ đề cập đến các tín hiệu thời gian thực bằng cách sử dụng các số được mã hóa cứng mà thay vào đó phải luôn luôn đề cập đến các tín hiệu thời gian thực bằng cách sử dụng ký hiệu SIGRTMIN + n và bao gồm các kiểm tra (thời gian chạy) phù hợp rằng SIGRTMIN + n không vượt quá SIGRTMAX.

Tôi cũng đã kiểm tra mã nguồn cho glibc; xem dòng 22 . __SIGRTMINđược tăng +2, vì vậy hai tín hiệu thời gian thực đầu tiên được loại trừ khỏi phạm vi tín hiệu thời gian thực.


Vậy làm thế nào để người ta có được giá trị hiện tại của SIGRTMIN trong thời gian chạy trong một đoạn mã thực thi?
SlySven

10

Bởi vì các tín hiệu là:

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

Cả hai đều không được hỗ trợ trong Linux. (LWP là viết tắt của Quy trình Ánh sáng )

Nguồn: Hướng dẫn chuyển đổi IBM DeveloperWorks Solaris sang Linux


Linux có tín hiệu 32 và 33. Xem: unixhelp.ed.ac.uk/CGI/man-cgi?signal+7 , Real-time Signalsphần.
cuonglm

@Gnouc - theo kill -l RTMINbắt đầu từ 34, không phải 32 theo tài liệu bạn tham chiếu. Điều này nói rằng nó bắt đầu từ 33, nhưng tiếp tục nói rằng bạn không nên tham chiếu chúng theo số vì các số có thể thay đổi tùy thuộc vào việc triển khai luồng glibc.
garethTheRed

Tất nhiên, nó thay đổi dựa trên hệ thống, nhưng thuật ngữ Linux không được hỗ trợ là không chính xác. Bạn có thể tham khảo điều này: cse.psu.edu/~dheller/cmpsc311/Lectures/Process-Control-Signals/ ,. Có lẽ chúng ta cần một vereran làm việc với Linux từ lâu để cho chúng ta biết điều gì xảy ra với tín hiệu 32, 33. Tại sao chúng không được ghi lại.
cuonglm

Chúng được sử dụng nội bộ bởi thư viện pthread RT - và trong quá khứ sẽ có ba chứ không phải hai vì một hệ thống khác được sử dụng nhiều cho mục đích nội bộ. Từ quan điểm mã hóa, bạn không được phép sử dụng các hằng số thời gian biên dịch cho các tín hiệu trên SIGSYS, ví dụ: một SIGRTMINtập hợp với một #definedòng vì số đó có thể thay đổi sau này khi chạy được. Điều này sẽ xuất hiện vài năm trước khi cả hai lib pthread được sử dụng nếu một ứng dụng được biên dịch dựa trên một thư viện pthread được chạy trên một hệ thống đã được khởi động lại với hệ thống kia!
SlySven
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.