ทำไม `kill -l 'ไม่แสดงหมายเลขสัญญาณ 32 และ 33


18

การดำเนินการkill -lบน linux ให้:

 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

เกิดอะไรขึ้นกับ32และ33? ทำไมมันไม่อยู่ในรายการ? พวกเขาน่าจะเริ่มต้นที่ 1 และจบลงที่ 62 แทนที่จะกระโดด 2 ตรงกลาง?


ป.ล. ไม่มี "รหัสข้อผิดพลาด" - เป็นหมายเลขสัญญาณ
G-Man กล่าวว่า 'Reinstate Monica'

คำตอบ:


20

มันเป็นเพราะNPTL เนื่องจากเป็นส่วนหนึ่งของไลบรารี GNU Cเกือบทุกการแจกจ่าย linux ที่ทันสมัยจึงไม่ใช้สัญญาณเรียลไทม์สองรายการแรกอีกต่อไป NPTL คือการนำPOSIXไปใช้งาน NPTL ใช้สัญญาณเรียลไทม์สองตัวแรกภายใน

ส่วนหนึ่งของmanpage สัญญาณนี้น่าสนใจมาก:

เคอร์เนล Linux รองรับสัญญาณเรียลไทม์ 32 ช่วงจำนวน 33 ถึง 64 อย่างไรก็ตามการใช้เธรด glibc POSIX ใช้ภายในสอง (สำหรับ NPTL) หรือสาม (สำหรับ LinuxThreads) สัญญาณเรียลไทม์ (ดู pthreads (7)) และปรับค่า SIGRTMIN ให้เหมาะสม (เป็น 34 หรือ 35) เนื่องจากช่วงของสัญญาณแบบเรียลไทม์ที่มีให้ใช้แตกต่างกันไปตามการใช้เธรด glibc (และการเปลี่ยนแปลงนี้สามารถเกิดขึ้นได้ในเวลาทำงานตามเคอร์เนลและ glibc ที่มี) และแน่นอนช่วงสัญญาณเรียลไทม์แตกต่างกันไปในระบบ UNIX ไม่อ้างถึงสัญญาณเรียลไทม์โดยใช้หมายเลขที่กำหนดรหัสยาก แต่ควรอ้างอิงสัญญาณเรียลไทม์โดยใช้สัญกรณ์ SIGRTMIN + n และรวมถึงการตรวจสอบ (เวลาทำงาน) ที่เหมาะสมที่ SIGRTMIN + n ไม่เกิน SIGRTMAX

ฉันยังตรวจสอบซอร์สโค้ดสำหรับ glibc ด้วย; ดูline 22 __SIGRTMINเพิ่มขึ้น +2 ดังนั้นสัญญาณเรียลไทม์สองรายการแรกจะถูกแยกออกจากช่วงของสัญญาณเรียลไทม์


ดังนั้นวิธีหนึ่งจะได้รับมูลค่าปัจจุบันของ SIGRTMIN ในเวลาทำงานในชิ้นส่วนของรหัสรัน?
SlySven

10

เพราะสัญญาณคือ:

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

ไม่รองรับ Linux (LWP ย่อมาจากกระบวนการ WeWeight )

ที่มา: IBM DeveloperWorks Solaris คู่มือการโอนย้ายระบบ Linux


ลินุกซ์มีสัญญาณ 32 และ 33. ดู: unixhelp.ed.ac.uk/CGI/man-cgi?signal+7 , Real-time Signalsส่วน
cuonglm

@Gnouc - ตามที่kill -l RTMINเริ่มต้นที่ 34 ไม่ใช่ 32 ตามเอกสารอ้างอิงของคุณ อันนี้บอกว่ามันเริ่มต้นที่ 33 แต่บอกต่อไปว่าคุณไม่ควรอ้างอิงพวกมันด้วยตัวเลขเพราะตัวเลขอาจแตกต่างกันไปขึ้นอยู่กับการใช้เธรด glibc
garethTheRed

แน่นอนมันแตกต่างกันไปขึ้นอยู่กับระบบ แต่คำว่า Linux ไม่ได้รับการสนับสนุนไม่ถูกต้อง คุณสามารถดูนี้: cse.psu.edu/~dheller/cmpsc311/Lectures/Process-Control-Signals/... บางทีเราอาจต้องการ vereran ที่ทำงานกับ Linux มานานแล้วเพื่อแจ้งให้เราทราบว่าเกิดอะไรขึ้นกับสัญญาณที่ 32, 33 ทำไมพวกเขาถึงไม่ทำเอกสาร
cuonglm

พวกเขาถูกใช้ภายในโดยไลบรารี RT pthread - และในอดีตจะมีสามไม่ใช่สองเนื่องจากระบบที่แตกต่างใช้หลายอย่างเพื่อวัตถุประสงค์ภายใน จากมุมมองของการเข้ารหัสคุณไม่ควรใช้ค่าคงที่เวลาคอมไพล์สำหรับสัญญาณด้านบน SIGSYS เช่นSIGRTMINชุดที่มี#defineบรรทัดเนื่องจากหมายเลขนั้นอาจเปลี่ยนแปลงได้ในภายหลังเมื่อเรียกใช้โปรแกรมปฏิบัติการ สิ่งนี้จะปรากฏขึ้นเมื่อไม่กี่ปีที่ผ่านมาเมื่อมีการใช้ทั้ง pthread libs หากแอปพลิเคชันที่คอมไพล์กับไลบรารี pthread หนึ่งถูกรันบนระบบที่ถูกรีบูตด้วยอีกอัน!
SlySven
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.