หลีกเลี่ยงการเรียกซ้ำเมื่ออ่าน / เขียนพอร์ตพร้อมกันหรือไม่?


108

การทำงานของพอร์ตทั้งหมดใน Rebol 3 เป็นแบบอะซิงโครนัส waitวิธีเดียวที่ฉันสามารถหาที่จะทำซิงโครการสื่อสารคือโทร

แต่ปัญหาในการโทรรอในกรณีนี้คือจะตรวจสอบเหตุการณ์สำหรับพอร์ตที่เปิดอยู่ทั้งหมด (แม้ว่าจะไม่อยู่ในบล็อกพอร์ตที่ส่งผ่านเพื่อรอ) จากนั้นจึงเรียกตัวจัดการเหตุการณ์ตอบกลับ แต่การอ่าน / เขียนสามารถทำได้ในตัวจัดการเหตุการณ์เหล่านั้น ซึ่งอาจส่งผลให้เกิดการเรียกซ้ำเพื่อ "รอ"

ฉันจะหลีกเลี่ยงสิ่งนี้ได้อย่างไร?


8
อันที่จริงฉันไม่คิดว่าจะมีวิธีแก้ปัญหานี้ในการใช้งาน R3 ปัจจุบันดังนั้นฉันจึงเพิ่มการปรับแต่ง "/ only" เป็น "wait" ซึ่งจะรอเฉพาะพอร์ตที่ให้ไว้เพื่อ "wait" และหลีกเลี่ยงการโทรซ้ำ ดูคำขอดึงของฉันได้ที่: github.com/rebol/rebol/pull/177
Shixin Zeng

1
ด้วยความอยากรู้อยากเห็นทำไมคุณต้องซิงโครนัส?
toadzky

1
มีหลายสถานการณ์ที่การเข้ารหัสด้วยพอร์ตซิงโครนัสนั้นง่ายกว่ามากสมมติว่าคุณต้องการส่งอีเมลด้วยการคลิกปุ่มและรายงานว่าสำเร็จหรือล้มเหลว ง่ายกว่ามากที่จะรอให้เสร็จสิ้นก่อนที่จะทำอย่างอื่น
Shixin Zeng

1
คุณต้องใช้ Rebol หรือไม่?
Rivenfall

1
ใช่. นี่เป็นคำถามเกี่ยวกับ Rebol 3 มากกว่าการสื่อสารแบบซิงโครนัสโดยทั่วไป
Shixin Zeng

คำตอบ:


1

เหตุใดคุณจึงไม่สร้างฟังก์ชัน "บัฟเฟอร์" เพื่อรับข้อความทั้งหมดจากรายการที่สัมพันธ์กันและประมวลผลเป็น FIFO (เข้าก่อนออกก่อน)

ด้วยวิธีนี้คุณสามารถรักษาคุณสมบัติ Assync ของพอร์ตของคุณและประมวลผลในโหมดซิงค์


0

ในกรณีที่มีเหตุการณ์ไม่ตรงกันเท่านั้นและเราต้องการการตอบกลับแบบซิงโครนัสเริ่มตัวจับเวลาหรือสลีปสำหรับการหมดเวลาหากตัวจัดการหรือวัตถุประสงค์ที่ต้องการเป็นไปตามนั้นให้พูดจริงมิฉะนั้นเป็นเท็จและตรวจสอบให้แน่ใจว่าเหตุการณ์ถูกยกเลิก / รีเซ็ตสำหรับ เหมือนกันถ้าสำคัญ


0

ฉันคิดว่ามีปัญหาในการออกแบบ 2 อย่าง (อาจจะอยู่ที่เครื่องมือ / วิธีแก้ปัญหาในมือ)

  1. Waitทำมากเกินไป - it will check events for all open ports. ในสภาพแวดล้อมที่ดีควรใช้การรอในที่ที่จำเป็นเท่านั้น: ต่ออุปกรณ์ต่อพอร์ตต่อซ็อกเก็ต ... การสร้างการพึ่งพาระหว่างกันที่ไม่จำเป็นระหว่างทรัพยากรที่ใช้ร่วมกันไม่สามารถจบลงได้ดีโดยเฉพาะอย่างยิ่งเมื่อทราบว่าทรัพยากรที่ใช้ร่วมกัน สามารถสร้างปัญหามากมาย

  2. ตัวจัดการเหตุการณ์อาจทำมากเกินไป ตัวจัดการเหตุการณ์ควรสั้นที่สุดและควรจัดการเฉพาะเหตุการณ์เท่านั้น หากทำได้มากกว่านั้นแสดงว่าตัวจัดการทำงานมากเกินไปโดยเฉพาะอย่างยิ่งหากเกี่ยวข้องกับทรัพยากรที่ใช้ร่วมกันอื่น ๆ ในหลาย ๆ สถานการณ์ตัวจัดการเพียงแค่บันทึกข้อมูลที่จะสูญหายไม่เช่นนั้น และงานอะซิงโครนัสจะทำสิ่งที่ซับซ้อนมากขึ้น


-1

คุณสามารถใช้ล็อค Cummunication1 สามารถตั้งค่าสถานะโกลบอลล็อกเช่นด้วยตัวแปร (ต้องแน่ใจว่าเธรดปลอดภัย) locked = true. จากนั้น Communication2 สามารถรอจนกว่าจะปลดล็อก

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

1
นี่เป็นคำถามเกี่ยวกับ Rebol 3 มากกว่าการสื่อสารแบบซิงโครนัสโดยทั่วไป
Shixin Zeng
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.