פתרון עומס חסימות ושרידות

הרישיון הוא חלק מן ה־context של הבקשה, ולא חלק מן ההמתנה של המשתמש. המשתמש יכול להפסיק להתעניין בתוצאה בעוד הקרנל עדיין משתמש ב־buffer. לכן callback הביטול רק מסמן כוונה ומבקש CancelIoEx; הוא אינו מאפס את ה־Lease.

המעבר שמשחרר את הרישיון נמצא במסלול הסיום היחיד, אחרי שצרכנו completion או אחרי שגיאת הגשה שמוכיחה שהפעולה לא התקבלה. כך אותה בקשה אינה משחררת את התקציב גם בזמן timeout וגם בזמן completion.

בדיקה ללא תזמון מקרי

אפשר לבנות backend מדומה שמקבל בקשות אך אינו משלים אותן עד שהבדיקה קוראת לפונקציה מפורשת. ארבע בקשות של ארבעת אלפים תשעים ושישה בתים ממלאות את שני הגבולות. בקשת ביטול אחת משאירה את הספירה ארבע. בקשה חמישית נדחית. רק לאחר שהבדיקה מזריקה completion של הביטול, בקשה חדשה יכולה להתקבל.

הבדיקה אינה מחקה את כל הקרנל. היא בודקת את חוזה הבעלות של המנוע מול סדר אירועים נשלט. לאחר מכן מריצים גם backend אמיתי כדי לבדוק שהתרגום בין WinAPI למכונת המצבים נכון.

זמן אחד לאורך המסלול

בעת הקבלה מחשבים deadline מתוך שעון מונוטוני ומעבירים אותו בתוך הבקשה. בכל שלב מחשבים את הזמן שנותר. אם המועד עבר לפני הגשה, אפשר לדחות בלי ליצור I/O. אם עבר בזמן פעולה פעילה, מבקשים ביטול וממשיכים לנקות גם אם התוצאה כבר לא תפורסם.

תוצאה שהגיעה אחרי deadline יכולה להירשם לצורכי אבחון, אך הממשק צריך להחזיר את המצב שהובטח ללקוח. אם הפעולה משנה מידע, אי אפשר להסיק מ־timeout שהיא לא התבצעה. בפרק האמינות נפריד בין תוצאת פעולה לבין ידיעת הלקוח עליה.

תלות פנימית במאגר

בתרחיש ה־future, כל עובד מחזיק משאב ביצוע וממתין לעבודה שזקוקה לאותו משאב. המעבד יכול להיות כמעט פנוי משום שכל התהליכונים ממתינים. הוספת עובד אחד מאפשרת התקדמות רק עד שנוצר עומס עם תלות עמוקה יותר.

תיקון אפשרי הוא לתזמן continuation כאשר ה־future מסתיים במקום לחסום את העובד. אפשרות אחרת היא להפריד מאגר לפעולות חוסמות, תוך גבול קבלה ברור. בכל מקרה צריך לשרטט את התלות ולוודא שהגורם שמסיים את העבודה אינו תלוי בעובד שהמתין לו.