פרויקט מנהל תהליכי עבודה

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

המצבים שהמערכת מכירה

ה־supervisor עובר דרך creating, assigned, starting, ready, stopping ו־exited. כשל בכל שלב מתועד עם הפעולה שנכשלה וקוד השגיאה. ילד שלא הגיע ל־ready בזמן אינו נחשב worker תקין רק משום שהיצירה הצליחה.

הילד נוצר suspended ומשויך ל־job לפני ResumeThread. ה־job מגביל את מספר התהליכים ומוגדר כך שסגירת ההפניה האחרונה אליו מסיימת את הקבוצה. אין להעביר את ה־job handle לילד.

ההורה והילד משתמשים בשני events: הודעת ready ובקשת stop. אפשר להעביר handles באמצעות רשימה מפורשת ב־STARTUPINFOEX, או להשתמש בשמות ייחודיים מקומיים ל־session עם מדיניות התנגשות מתועדת. אין להפעיל ירושה כללית של כל handles.

סיום עם שתי דרגות

במצב רגיל הילד מסיים עבודה ומשחרר משאבים אחרי stop. במצב בדיקה נוסף הוא מתעלם מהבקשה, וההורה מפעיל deadline ואחריו termination כפוי של ה־job. הדוח חייב להבדיל בין שני המצבים, גם אם שניהם מסתיימים בלי process שנותר ברקע.

ההורה ממתין לאישור סיום דרך אובייקט התהליך ואוסף exit code. הוא אינו מסתפק בהצלחת TerminateJobObject. אין להניח ש־destructors של הילד רצו במסלול הכפוי.

ניסויי קבלה

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

אספו זמני user ו־kernel של הילד וזמן קיר כולל. הסבירו למה ההמתנה ל־stop אינה מופיעה כזמן CPU מלא. שמרו trace אחד של creation עד exit או תיעוד מפורש שהכלי לא היה זמין.

ההגשה כוללת קוד, פקודות בנייה, טבלת בעלות לכל handle ותרשים מצבים. בדוח יש להסביר למה job אינו sandbox, למה PID אינו מספיק למעקב אחרי ילד מסוים ומה קורה אם ההורה עצמו כבר נמצא ב־job.