פתרון פרויקט מנוע עבודה אסינכרוני

הפתרון נותן לכל ניסיון operation object שמחזיק את הOVERLAPPED ואת האחסון הדרוש להשלמה. הframe אינו רשאי להיעלם כל עוד נתיב completion מחזיק כתובת לתוכו. אפשר להחזיק state נפרד ולחדש דרך registration שניתן לבטל, או לקשור את חיי הframe לפעולה עד quiescence.

המעבר המרכזי הוא בין created, submitted וcompleted. כשל סינכרוני לפני שהAPI קיבל את הבקשה מנוקה בידי המגיש. בקשה שהתקבלה מנוקה דרך המסלול שהחוזה שלה קובע. אין להפעיל את שני המסלולים רק משום שהפונקציה החזירה ערך שנראה כמו שגיאה בלי לבדוק pending.

הביטול מסמן כוונה ופונה לAPI המתאים. הוא אינו מוציא את operation object מטבלת החיים עד להשלמה האחרונה. תוצאה מוצלחת שמגיעה במרוץ עם cancel נשארת תוצאה מותרת אם כך הAPI הכריע. הclient יכול להפסיק להמתין בלי לשחרר את מצב הI/O.

הcapacity נספר לפי זיכרון שמוחזק בפועל. פעולה שסיימה קריאה אבל מחכה שclient יקרא את התוצאה עדיין צורכת buffer. לכן יש תקציב גם לoutbox ולא רק למספר הבקשות שבקרנל.

הבדיקה הדטרמיניסטית משתמשת בbackend מדומה שמחזיר השלמות בסדרים נבחרים, כולל השלמה שמגיעה מיד אחרי submit. בדיקת הIOCP האמיתית מאמתת את החיבור לAPI ואת נתיבי ההשלמה שלו. שתי הבדיקות משלימות זו את זו; המודל אינו מריץ קרנל, והstress אינו מונה את כל התזמונים האפשריים.

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