KAL
Menu

Monitor

Pengamatan kegagalan proses secara satu arah dan pemilihan monitor versus link.

Daftar isi

Topik ini membahas monitor sebagai pelengkap link yang kepentingannya berbeda: mengamati keberadaan satu proses tanpa terikat pada nasibnya. Pembahasan mencakup monitor/2, pesan DOWN yang dihasilkan, demonitor, dan pedoman memilih antara monitor dan link.

Monitor dan pesan DOWN#

Fungsi monitor/2 mendaftarkan pengamat satu arah: proses yang memantau akan diberi tahu saat proses yang dipantau berakhir, tetapi kegagalan proses yang dipantau tidak memengaruhi pengamatnya sama sekali. Nilai kembaliannya adalah referensi unik, dan saat proses yang dipantau berakhir, pesan tuple {'DOWN', Ref, process, PID, Alasan} masuk ke mailbox pengamat:

erlang Memantau proses dan membaca DOWN 
Erlang/OTP 29 [erts-17.1.1] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]

Eshell V17.1.1 (press Ctrl+G to abort, type help(). for help)
1> P = spawn(fun() -> receive after 30000 -> ok end end).
<0.87.0>
2> Ref = monitor(process, P).
#Ref<0.3394532810.1553727489.31008>
3> exit(P, selesai).
true
4> flush().
Shell got {'DOWN',#Ref<0.3394532810.1553727489.31008>,process,<0.87.0>,
                  selesai}

Proses yang dipantau pada contoh hanya menunggu, sehingga satu-satunya cara ia berakhir adalah panggilan exit/2 dari shell. Pesan DOWN membawa empat hal yang dibutuhkan pengamat: referensi monitor, jenis sumber, PID proses yang berakhir, dan alasan berakhirnya. Referensi menjadi kunci pembanding yang aman ketika satu proses memantau banyak proses sekaligus, karena setiap pemantauan punya referensinya sendiri.

Kegagalan dan pesan DOWN#

Alasan pada pesan DOWN mencerminkan cara proses berakhir: alasan yang dikirim lewat exit/2, normal untuk berakhir secara normal, atau bentuk error semacam {badarith, ...} bila proses berhenti karena exception. Perilakunya konsisten: monitor tidak membatasi cara proses berakhir, dan pengamat tetap menerima satu pesan DOWN dalam semua kasus. Sifat ini membuat monitor cocok untuk pengelola sumber daya eksternal, misalnya proses yang menjaga koneksi jaringan, karena pengamat tetap hidup dan bebas memutus tindak lanjutnya sendiri.

Memantau proses yang sudah mati#

Monitor juga menangani kasus yang jarang dibicarakan: target sudah tidak ada saat monitor dibuat. Alih-alih gagal diam-diam, monitor segera mengirim pesan DOWN dengan alasan noproc, sehingga pengamat selalu menerima jawaban:

erlang Monitor atas proses yang sudah berakhir 
1> P = spawn(fun() -> ok end).
<0.87.0>
2> Ref = monitor(process, P).
#Ref<0.3827097070.213647362.112199>
3> flush().
Shell got {'DOWN',#Ref<0.3827097070.213647362.112199>,process,<0.87.0>,noproc}
ok

Proses pada contoh berakhir seketika setelah dibuat, sehingga monitor yang menyusul langsung melaporkan noproc. Jaminan ini menghilangkan satu jenis ketidakpastian: pengamat tidak perlu menebak apakah target masih hidup, karena satu-satunya kontraknya adalah pesan DOWN pasti datang, entah saat target berakhir atau seketika saat monitor dibuat.

Melepas monitor#

Monitor yang tidak lagi dibutuhkan dilepas dengan demonitor/2. Opsi [flush] sekaligus membuang pesan DOWN yang mungkin sudah menunggu di mailbox, sehingga tidak ada jejak yang tertinggal:

erlang Melepas monitor dengan bersih 
5> demonitor(Ref, [flush]).
true

Tanpa opsi [flush], pesan DOWN yang sudah dalam perjalanan tetap tiba dan harus ditangani oleh receive yang tepat. Detail ini penting pada kode yang memantau proses berumur pendek secara berulang, karena pesan DOWN dari monitor lama yang tak dibersihkan akan bercampur dengan pesan pemantauan baru.

Keduanya memberi tahu tentang berakhirnya proses, dan pilihannya ditentukan oleh kebutuhan: mempertahankan kebenaran bersama atau sekadar memperoleh informasi.

AspekLinkMonitor
Arahdua arahsatu arah
Akibat defaultikut berakhirtidak ada, hanya pesan
Bentuk pemberitahuansinyal exitpesan DOWN berreferensi
Penggunaan khaspohon supervisi, kerja berpasanganpengelola proses bantu, klien ke layanan

Link menjawab hubungan yang saling bergantung untuk kebenaran: keduanya harus hidup atau mati bersama, dan supervisor memakai link pada seluruh pohon supervisinya. Monitor menjawab hubungan yang hanya memerlukan informasi: pengamat tetap hidup dan memutus sendiri tindakannya, sebagaimana klien yang memantau servernya lalu menyambung ulang saat menerima DOWN. Kedua mekanisme dapat dipakai bersamaan pada pasangan proses yang sama, dan OTP memakai keduanya sesuai peran masing-masing.

Kesalahan umum#

  • Membaca pesan DOWN tanpa membandingkan referensinya. Pada proses yang memantau banyak target, pesan DOWN dari target lain tertangkap oleh receive yang ceroboh. Cocokkan Ref dari kembalian monitor/2 pada pola receive, atau sertakan referensi di pesan permintaan-balasan.
  • Mengandalkan monitor untuk keselamatan bersama. Monitor tidak membuat proses ikut berakhir. Bila kebenaran program bergantung pada hidup-matinya target, yang dibutuhkan adalah link dan supervisi, bukan monitor.
  • Membiarkan monitor tertanam pada loop yang berulang. Monitor yang dibuat ulang setiap iterasi tanpa demonitor/2 menumpuk pesan DOWN di mailbox, dan pembersihannya menjadi pekerjaan yang tak pernah selesai.

Ringkasan#

  • monitor/2 memantau satu proses secara satu arah dan mengembalikan referensi unik.
  • Berakhirnya proses yang dipantau mengirim pesan {‘DOWN’, Ref, process, PID, Alasan} ke mailbox pengamat, tanpa memengaruhi hidup-matinya pengamat.
  • demonitor/2 dengan opsi [flush] melepas monitor sekaligus membuang pesan DOWN yang menunggu.
  • Link untuk hubungan yang benar bersama hidup dan mati, monitor untuk hubungan yang cukup diberi tahu. Pilihannya ditentukan oleh kebutuhan kebenaran, bukan selera.

Referensi#