Siapa yang memutuskan aplikasi mana yang menerima sinyal dari keyboard?


16

Pemahaman saya saat ini tentang sinyal dari keyboard di terminal (sebagian besar didasarkan pada upaya memetakan pengamatan saya ke apa yang dapat ditemukan di google) berikut:

  • Pengguna menekan Cc
  • Ini dikirim ke input buffer terminal sebagai byte yang dihitung dengan membersihkan 2 bit paling kiri dari 7 bit nilai ascii dari c

Setelah ini mulai benar-benar berkabut, karena konfigurasi input apa artinya sinyal apa yang dilakukan di terminal (stty). Saya kira itu berarti terminal itu sendiri mengirimkan sinyal ke proses. Tapi saya juga pikir terminal itu tidak tahu tentang aplikasi yang membacanya.

Bagaimana cara mengirim sinyal dengan keyboard di terminal bekerja dari ujung ke ujung?


1
Bukan jawaban sendiri, tetapi layak dibaca: TTY demistified , oleh lft.
duskwuff

Jawaban:


33

Menekan Csambil Ctrlditekan mengirimkan penekanan tombol diikuti oleh peristiwa rilis X11 ke emulator terminal.

Setelah peristiwa itu (umumnya yang menekan tombol), terminal emulator menulis byte 0x3 ( ^C) ke deskriptor file di sisi master perangkat pseudo-tty.

Jika isigpengaturan termios perangkat aktif dan jika intrpengaturan diatur ke 0x3 byte itu, maka kernel mengirimkan sinyal SIGINT ke semua anggota kelompok proses latar depan perangkat terminal (atribut lain yang disimpan dalam perangkat pty). Dalam hal ini, byte 0x3 tidak akan tersedia untuk dibaca di sisi slave pty.

Biasanya shell interaktif yang membuat grup proses (dengan setpgid()) untuk pekerjaan shell, dan memutuskan yang mana yang akan diletakkan di latar depan (dengan tcsetpgrp()mengatur atribut perangkat pty itu) atau tidak.

Misalnya ketika Anda menjalankan prompt shell interaktif:

foo | bar

Shell memulai grup proses baru dengan dua proses (di mana ia mengeksekusi foodan barsetelah menghubungkan stdin / out dengan pipa) dan menempatkan grup itu di latar depan. Kedua proses akan menerima SIGINT jika Anda menekan Ctrl-C.

Di:

foo | bar &

Sama tetapi grup proses tidak diletakkan di latar depan (dan shell juga tidak menunggu sehingga Anda dapat memasukkan perintah lain). Proses-proses itu tidak akan mendapatkan SIGINT pada Ctrl-C tetapi dapat ditangguhkan jika mereka mencoba membaca dari perangkat tty.

Lebih banyak membaca di: Apa tanggung jawab masing-masing komponen Pseudo-Terminal (PTY) (perangkat lunak, sisi master, sisi budak)?


2
Terima kasih atas jawaban yang kaya. Saya akan mencoba untuk mengulangi inti dari jawaban untuk memastikan bahwa saya memahaminya: Sinyal dikirim oleh kernel, yang memantau perangkat tty itu sendiri untuk input yang dikonfigurasi dalam atribut perangkat (oleh siapa pun yang ingin mengkonfigurasinya) dan kernel mengirimkannya ke grup proses yang juga dikonfigurasi dalam atribut perangkat (terutama oleh shell sebagai salah satu tugas dari pemimpin sesi). Saya harap ini benar.
calavera.info

1
@ calavera.info, ya itu benar. Dalam kasus terminal nyata di ujung kabel serial, kernel mencari byte 0x3 yang berasal dari kabel. Untuk terminal semu, sisi master mengganti kabel. Dan kernel mencari byte 0x3 dalam byte yang dikirim ke sana oleh terminal emulator. Lihat juga hasil edit dengan tautan ke T&J lain dengan lebih detail (seperti fakta bahwa pemrosesan kernel merupakan bagian dari desain modular yang dilakukan ketika perangkat digunakan sebagai perangkat "terminal" ( disiplin jalur terminal )
Stéphane Chazelas

Bukankah pertanyaannya mengatakan terminal , bukan emulator terminal ? Saya tidak mengira itu membuat banyak perbedaan, mengingat bahwa fungsi emulator adalah untuk bertindak sebanyak terminal mungkin ...
Toby Speight

2
@Toby, ya, karena hampir tidak ada yang menggunakan terminal nyata hari ini, saya mengasumsikan emulator terminal yang dimaksudkan OP (banyak dari mereka disebut "terminal"). Lihat juga komentar saya di atas milik Anda dan Tanya Jawab terkait untuk detail lebih lanjut.
Stéphane Chazelas

1
@TobySpeight Ya, saya bertanya tentang terminal karena saya berurusan dengan terminal nyata melalui saluran serial, tetapi jawaban dan komentar berikut benar-benar berlaku untuk kedua kasus.
calavera.info
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.