Menghindari rekursi saat membaca / menulis port secara sinkron?


108

Semua operasi port di Rebol 3 tidak sinkron. Satu-satunya cara yang dapat saya temukan untuk melakukan komunikasi sinkron adalah menelepon wait.

Tetapi masalah dengan memanggil tunggu dalam kasus ini adalah bahwa ia akan memeriksa kejadian untuk semua port yang terbuka (bahkan jika mereka tidak berada dalam blok port yang dilewatkan untuk menunggu). Kemudian mereka memanggil penangan peristiwa yang menanggapi, tetapi membaca / menulis dapat dilakukan di salah satu penangan peristiwa tersebut. Itu bisa mengakibatkan panggilan rekursif untuk "menunggu".

Bagaimana cara menyiasati ini?


8
Sebenarnya, saya tidak berpikir ada solusi untuk ini dalam implementasi R3 saat ini, jadi saya melanjutkan untuk menambahkan perbaikan "/ hanya" untuk "menunggu", yang hanya akan menunggu pada port yang disediakan untuk "menunggu" , dan karenanya hindari panggilan rekursif. Lihat permintaan tarik saya di: github.com/rebol/rebol/pull/177
Shixin Zeng

1
Karena penasaran, mengapa Anda membutuhkannya agar sinkron?
toadzky

1
Ada banyak situasi dimana pengkodean dengan port sinkron jauh lebih mudah: misalkan Anda ingin mengirim email dengan mengklik tombol, dan laporkan jika berhasil atau gagal. Jauh lebih mudah untuk menunggu sampai selesai sebelum melakukan hal lain.
Shixin Zeng

1
apakah Anda benar-benar harus menggunakan Rebol?
Rivenfall

1
Iya. Ini sebenarnya lebih merupakan pertanyaan tentang Rebol 3 daripada komunikasi sinkron pada umumnya.
Shixin Zeng

Jawaban:


1

Mengapa Anda tidak membuat semacam fungsi "Buffer" untuk menerima semua pesan dari entri assyncronous dan memprosesnya sebagai FIFO (first-in, first-out)?

Dengan cara ini Anda dapat mempertahankan karakteristik Assync dari port Anda dan memprosesnya dalam mode sinkronisasi.


0

dalam kasus di mana hanya ada acara asinkron dan kami membutuhkan balasan sinkron, mulai pengatur waktu atau tidur untuk waktu habis, jika penangan atau tujuan yang diperlukan terpenuhi maka katakan benar, jika tidak salah dan pastikan acara dibatalkan / reset untuk sama jika kritis.


0

Saya pikir ada 2 masalah desain (mungkin intrinsik dengan alat / solusi yang ada).

  1. Waitmelakukan terlalu banyak - it will check events for all open ports. Dalam lingkungan yang sehat, menunggu harus diimplementasikan hanya jika diperlukan: per perangkat, per port, per soket ... Membuat antar-ketergantungan yang tidak perlu antara sumber daya bersama tidak dapat diakhiri dengan baik - terutama mengetahui bahwa sumber daya bersama (bahkan tanpa antar-ketergantungan) bisa menimbulkan banyak masalah.

  2. Penangan acara mungkin melakukan terlalu banyak. Penangan acara harus sesingkat mungkin, dan hanya menangani acara tersebut. Jika berbuat lebih banyak, maka pawang melakukan terlalu banyak - terutama jika melibatkan sumber daya bersama lainnya. Dalam banyak situasi, pawang hanya menyimpan data yang akan hilang jika tidak; dan pekerjaan asinkron akan melakukan hal-hal yang lebih kompleks.


-1

Anda bisa menggunakan kunci. Cummunication1 dapat mengatur beberapa status kunci global yaitu dengan variabel (pastikan bahwa thread itu aman). locked = true. Kemudian Communication2 dapat menunggu hingga tidak terkunci.

loop do
    sleep 10ms
    break if not locked
end
locked = true
handle_communication()

1
Ini sebenarnya lebih merupakan pertanyaan tentang Rebol 3 daripada komunikasi sinkron pada umumnya.
Shixin Zeng
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.