תומרקוד

אחת התכונות החזקות ביותר בראסט היא מקביליות ואסינכרוניות, וכשמדברים על תכנות אסינכרוני tokio  היא הספרייה הנפוצה ביותר. אחד הפיצ׳רים המרכזיים שטוקיו מאפשרת הוא channels, אשר מאפשרים תקשורת בין חלקים שונים בתכונה שלנו. קיימים בראסט מגוון סוגים של channels שמגיעים ממגוון ספריות (כמו crossbeam , std::mpsc וכו׳). בפוסט אדבר על Tokio Channels, ומתי ואיך נשתמש בהם. מהם צ׳אנלים? כשם כן הם - ״ערוצים״ אשר מאפשרים דרך לשלוח נתונים בין חלקים שונים של תוכנה (בדרך כלל בין threads או tasks). צ׳אנלים מורכבים משני מרכיבים עיקריים:  שולח (Sender):  החלק ששולח נתונים ו מקבל (Receiver): החלק שמקבל נתונים. MPSC (Multi Producer Singler Consumer) הספריה tokio מאפשרת לנו שימוש בצ׳אנלים מסוג MPSC - כלומר, מספר tasks יכולים לשלוח מידע אל מקבל יחיד. וזה נותן לנו יכולת נוחה וישירה להעביר מידע מאיזה סוג שנבחר, אל task מקבל שבו נעבד את המידע ונתמודד איתו. דוגמה פשוטה: בדוגמה הזו אנחנו רואים את יצירת השולח והמקבל tx ו rx. לאחר מכן, יצירת task ברקע ששולח בלולאה 10 מספרים באמצעות tx אל ה task הראשי בו ...

כחלק מהמסע שלנו לניהול שגיאות נכון  נפל לנו האסימון שלהשתמש ב unwrap או expect  יכול להיות רעיון לא כל כך טוב ועלול להביא לסיום מיידי של הפרוסס שלנו במקרים שאולי לא התכוונו אליהם. אז השתמשנו ב clippy deny unwrap used  שגרם לקומפילציה לא לעבור במידה ונכנס unwrap לקוד. המקום היחיד בו היינו צריכים להשאיר unwrap היה בסט הוולידציות ההתחלתי בעליה של הפרוסס שלנו, בפונקציית ה main. לדוגמה - בניסיון למשוך את הקונפיגורציה הראשונית בעליה - אם נכשלנו מסיבה כלשהי נהרוג את הפרוסס. לימים פונקציית ה main הכילה יותר ויותר ולידציות כאלה ובנוסף גם התחלנו להרוג את הפרוסס שלנו כחלק מתהליך פונקציונאלי תקין במקרים מסויימים (exit code). בפוסט אנסה להציג את האלטרנטיבה שבחרנו לטיפול בשגיאות ב main באמצעות unwrap איך נראה main סטנדרטי הפריע לי בעין לראות כל כך הרבה unwrap וחיפשתי דרך נקייה יותר לנהל את השגיאות שעלולות לצוץ ב main. באחת מעשרות השיחות הטכניות שלי על ראסט עם המנטור שלי , הוא העלה את האופציה פשוט להחזיר result מפונקציית ה main וככה אם תוחזר שגיאה ב main היא תפועפע שכבה אחת והתכנית תסגר...