Signal Delivery — operatsion tizim pending signalni tanlangan process yoki threadning bajarilish oqimiga kiritib, uning dispositioniga muvofiq amal bajaradigan jarayon. Signal generation va delivery bir xil payt bo‘lishi shart emas: masklangan signal pending qoladi, thread yana user mode’ga qaytayotganda yoki interruptible kutishdan uyg‘onganda yetkaziladi.
Signalning yaratilishi
Signal boshqa processning kill chaqiruvi, terminal tugmasi, timer, child process holati yoki CPU exceptioni natijasida hosil bo‘ladi. Kernel sender credential va target permissionini tekshiradi. Synchronous fault signali aynan fault qilgan threadga bog‘liq, process-directed signal esa mos threadlardan biriga tanlanishi mumkin.
Signal metadata’sida sender PID/UID, queue value, fault address yoki sabab kodi bo‘lishi mumkin. User space bu maydonlarni signal turiga mos talqin qiladi; barcha signallar uchun hamma maydon yaroqli emas.
Threadni tanlash
Thread-directed API konkret threadni nishonlaydi. Process-directed signal esa uni bloklamagan, deliveryga yaroqli threadga beriladi. Tanlov scheduler timingiga bog‘liq bo‘lishi mumkin. Dedicated sigwait thread modeli boshqa threadlarda mask qo‘yib tanlovni deterministik qiladi.
Synchronous SIGSEGVni boshqa threadga ko‘chirish mumkin emas; fault qilgan instruction state’i o‘sha threadga tegishli. U signalni bloklagan yoki e’tiborsiz qoldirgan bo‘lsa xulq maxsus qoidalarga ega va odatda normal recovery yo‘li emas.
User frame
Custom handler tanlansa kernel user stackda signal frame yaratadi. Unda saved registerlar, oldingi mask va return uchun trampoline ma’lumoti joylashadi. Handler argumentlari shu frame va kernel metadata’dan tayyorlanadi. Stack yetarli bo‘lmasa ikkilamchi fault yuz berishi mumkin.
Alternate signal stack stack-overflow kabi holatda handlerga alohida joy beradi. Uning hajmi nested signal, architecture state va runtime talabiga yetarli bo‘lishi kerak. Guard page overflowni aniqlashga yordam beradi.
Handlerdan qaytish
Handler oddiy return qilganda trampoline maxsus sigreturn system callini bajaradi. Kernel saved contextni tekshiradi, oldingi maskni va instruction pointer’ni tiklaydi. Soxta frame orqali privilege yoki kernel state o‘zgartirilmasligi uchun user qaytish state’i validatsiya qilinadi.
Handler contextni ataylab o‘zgartirishi mumkin bo‘lgan runtime’lar platforma ABI’siga qattiq bog‘liq. Portable application bunday usulga tayanmaydi.
Default action
Disposition default bo‘lsa signal processni tugatishi, core dump yaratishi, to‘xtatishi, davom ettirishi yoki e’tiborsiz qoldirilishi mumkin. Default ma’no signal raqamiga bog‘liq. SIGCHLD kabi signalning default xulqi process reaping semantikasiga ta’sir qilishi mumkin.
Blocking system call delivery sabab EINTR bilan qaytishi yoki restart flaglariga ko‘ra kernel tomonidan qayta boshlanishi mumkin. Partial I/O allaqachon data uzatgan bo‘lsa natija bayt soni bo‘lishi ehtimol.
Scheduler bilan bog‘lanish
Target thread interruptible sleepda bo‘lsa signal uni uyg‘otib, wait primitive’ni xato yoki restart holatiga olib keladi. Uninterruptible kernel kutishi esa signal pending bo‘lsa ham resurs hodisasi tugamaguncha davom etishi mumkin. “Signal yuborildi” thread darhol user handlerga kirdi degani emas. Delivery latency scheduler priority, CPU bandligi, mask va kernel critical sectionga bog‘liq.
Debugger ta’siri
Ptrace debugger signal generation bilan application delivery orasida to‘xtash nuqtasini olishi mumkin. Debugger signalni suppress, almashtirish yoki davom ettirishga qaror qiladi. Shu sabab debugger ostidagi timing va disposition productiondan farq qilishi ehtimol. Crash tahlilida signalning original cause kodi va debugger bergan replacement ajratiladi; aks holda sun’iy signal haqiqiy fault deb talqin qilinadi.
Bog‘liq tushunchalar
pending signal, signal frame, sigreturn, alternate stack, synchronous signal, signal disposition