Windows שירות בDelphi: מימוש נכון של כיבוי מבוקר עם TEvent ו-Stop-Timeout

יישום של Windows Service בDelphi נראה ביום-יום לעיתים בלתי מרשים: פועל ברקע, מעבד עבודות, כותב לוגים, מדבר עם מסדי נתונים או REST-APIs. עד שמישהו לוחץ על „סיום שירות“ — או מגיע Patch-Reboot — והשירות לא עוצר בצורה נקייה. אז קונסולת השירותים מציגה במשך דקות „מסתיים…“, השירות נתקע במצב בהמתנה לעצירה, ובמקרה הגרוע התהליך מנותק בכוח. כאן כדאי להתייחס לWindows Service בDelphi השבתה מסודרת כנושא ארכיטקטוני מודע: עם אות השבתה ברור, Timeouts מוגדרים וחוטים שמגיבים באמת.

במאמר זה אין מדובר בפנימיות של Frameworks, אלא בדפוס מעשי: TEvent כאות עצירה (אובייקט סינכרון קרוב ל‑Kernel מ־System.SyncObjs), בשילוב עם אסטרטגיית Stop-Timeout שמתחשבת גם ב־Windows Service Control Manager (SCM, כלומר ברכיב ה־Windows שמפעיל/עוצר שירותים) וגם ב־Worker‑Threads שלך. בנוסף מקרים שוליים טיפוסיים, שיטות דיבאג והדיון מתי לוגיקה נוספת אכן מצדיקה את עצמה.

Windows Service בDelphi — השבתה מסודרת בפרקטיקה

הסיבה השכיחה ביותר פשוטה: לשירות יש לפחות חוט אחד שנמצא בתוך פעולה חוסמת ולא ידוע לו מסלול עצירה. מקרים טיפוסיים:

• Polling‑Schleifen mit Sleep: „while not Terminated do Sleep(1000)“. בעת עצירה האות מתקבל, אך החוט מגיב רק לאחר עד שנייה אחת (או 30 שניות…).
• Blockierende I/O: Datenbank‑Calls, HTTP‑Requests, Named Pipes, Filesystem‑Waits – כל מה ש“פשוט ממתין“ בלי להקשיב לאות עצירה.
• Queue‑Consumer ohne Wakeup: עובד (Worker) מחכה לתור, אך בעת עצירה הוא לא מעורר כדי לצאת.
• Lock‑Reihenfolge/Deadlocks: בעת עצירה מבצעים „Cleanup“ בעוד חוטים אחרים עדיין מחזיקים Locks. זה מתרחש לעיתים רק במסלול העצירה, כי הסדר שם שונה מהסדר בזמן הרגיל.

ה‑Windows SCM מצפה ששירות יגיב במהירות לפקודת עצירה וידווח על מצבו באופן רציף (דרך SetServiceStatus; Delphi עוטפת זאת ברכיב השירות). אם אתה מקבל אירוע עצירה אך לא מכבה את ה־Threads שלך בצורה נקייה, התהליך נשאר חי — וWindows יחליט בסופו של דבר ש“זה לוקח יותר מדי זמן“. התוצאה תהיה או קריעה קשה של התהליך או שירות שנשאר תקוע בעולם ביניים לא ברור.

עיקרון יסוד: אות עצירה שכל Worker מבין

השבתה מסודרת פועלת רק אם יש לך אות ש:

• ניתן לכל ה־threads הרלוונטיים לצפות בו,
• משפיע גם מתוך מצבי המתנה חסימתיים,
• בנתיב ה-Stop הוא דטרמיניסטי (אין תקווה של „אולי הוא יצא מתישהו“),
• יש לו אסטרטגיית Timeout ברורה.

בDelphi ה-TEvent הוא כלי שימושי לכך: אובייקט אירוע שממומש פנימית באמצעות Windows-Handles (בדומה ל-CreateEvent/SetEvent). ניתן להשתמש בו כאות „Stop requested“. כל Worker לא יחכה בעיוורון, אלא יחכה „לעבודה או לעצירה“.

בחירת TEvent נכונה: ManualReset vs. AutoReset

באותות Stop בדרך כלל תרצה Manual Reset (ניתן לאיפוס ידני): ברגע שהוא מוגדר, ה-Event נשאר „signaled“ עד שתאפס אותו. כך מובטח שכל Thread שייכנס למצב המתנה מאוחר יותר יזהה את אות העצירה. Auto Reset מסוכן כאן, מכיוון שהוא מאפס את האות אוטומטית אחרי Thread שמחכה ואחרים עלולים לפספס את אות ה-Stop.

מחזור החיים של שירות Delphi: היכן ה-Stop מגיע בפועל

שירות Delphi-Windows- ו-Linux-Services מבוסס טיפוסית על TService (VCL/RTL). ה-SCM שולח פקודות (Start, Stop, Pause, Continue). Delphi קורא אז לאירועים/שיטות המתאימות (לפי התבנית, למשל OnStart, OnStop, OnExecute).

חשוב לארכיטקטורה:

• OnStop אינו מקום להמתנה ארוכה ללא עדכוני סטטוס. זה המקום שבו אתה מאתחל את ה-Shutdown ואז ממתין באופן מבוקר – עם Timeout.
• OnExecute בדרך כלל לולאה. אם אתה עובד שם „ללא סוף“, הלולאה חייבת להגיב לאות Stop.
• Worker-Threads (TThread או Thread-pools) צריכים להגיב לאותו אות Stop, אחרת השירות נעצר לוגית אך בפועל עדיין לא גמור.

תבנית נקייה: Stop-Event + Join של ה-Worker + Fallback קשיח

התבנית המעשית כוללת ארבעה שלבים:

1. בקשת Stop: הגדר את Stop-Event, אל תקבל עוד עבודות חדשות.
2. הפעלת Wakeups: אם ה-Workers מחכים בתורים או במצב Sleep, הם חייבים להיות מסוגלים „להתעורר“ (למשל באמצעות אות Event/Queue).
3. סגירה מסודרת: ה-Workers מסיימים את הלולאות שלהם, סוגרים משאבים (חיבורי DB, קבצים, Handles) ומדווחים „גמור“.
4. Timeout ו-Fallback: אם לא כל דבר מסתיים בזמן, עליך לקבל החלטה: להמשיך להמתין (עם עדכון סטטוס) או לקטוע באופן מבוקר/להפסיק בכוח (תלוי בסיכון).

העיקר הוא: אין שום Thread שיכול להמתין אך ורק על בסיס זמן (Sleep) או להיחסם אך ורק על I/O, מבלי להתחשב במקביל באות Stop. במקום זאת יש להשתמש בפונקציות המתנה שמביאות בחשבון מספר אותות (למשל „Stop-Event או Work-Event“), או לעטוף I/O ב-Timeouts בתוספת בדיקות Stop.

לחשוב נכון על Stop-Timeout: SCM-Timeout לעומת Shutdown-Timeout משלך

כאן מתרחשים בפרויקטים רוב אי-ההבנות. יש שתי רמות Timeout שונות:

• ציפיית ה‑SCM: Windows מצפה שתדווח באופן שוטף על התקדמות במצב SERVICE_STOP_PENDING. אחרת זה נראה כאילו אתה נתקע. Delphi מטפל בכך בחלקו, אבל ברגע שאתה נחסם לעצמך לפרק זמן ארוך יותר, אתה צריך אסטרטגיה איך לאפשר המשך עדכוני סטטוס (או איך לשמור על שלב ה‑Stop קצר).
• ה‑Shutdown‑Timeout שלך: אתה מגדיר למשל „נותנים לעצמנו 20 שניות לסיים עבודות רצות בצורה נקייה, ואז מפסיקים“. זו החלטת ארכיטקטורה: עקביות נתונים מול אילוץ אתחול מול דרישות תפעוליות.

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

כמה זמן מותר ש‑Stop ימשך?

אין מספר קסם שמתאים תמיד. עבור שירותי Business רבים טווח יעד של 5–30 שניות הוא ריאלי: מספיק זמן לנתונים בתעבורה, אבל קצר דיו לחלונות עדכון. אם אתה באופן קבוע צריך יותר זמן, זה לרוב סימן שאתה מעבד יחידות גדולות מדי בבת אחת או שתלויות חיצוניות (DB/HTTP) רצות ללא Timeout.

מימוש בעזרת TEvent: מבנה שמייצב את התפעול

מבנה מבוסס ביחידת שירות Delphi נראה כך (ללא אירוח יתר של פרטי Framework):

• אירוע עצירה (Stop‑Event) (TEvent, Manual Reset), שמוגדר ב‑Stop.
• איש או מספר תהליכי Worker, שמבחינת הלולאה הראשית שלהם בודקים מעת לעת את ה‑Stop.
• אופציונלית Work‑Event או תור שמשדר עבודה. ה‑Worker ממתינים אז ל“עבודה או Stop“.
• שלב Shutdown שמבצע join ל‑Worker (כלומר ממתין עד שיעצרו), אך עם Timeout.

החשוב אינו האם אתה משתמש ב‑TThread, ב‑omnithreadlibrary או ב‑Pool משלך, אלא שה‑Worker שלך לא רצים „בעיוורון“. לולאת Worker צריכה להיות מבנית כך: המתנה לאירוע(ים) → עבודה בחתיכות קטנות → בדיקת Stop בין חתיכות → שחרור משאבים נקי.

מלכודת: Terminate לבדו לא מספיק

הרבה Threads ב‑Delphi מקבלים Terminate כ“ביטול“. אבל זה רק דגל. אם ה‑Thread נמצא כרגע בתוך קריאת API חוסמת, לא יקרה כלום מיד. לכן אירוע Stop נפרד הוא כל כך שימושי: אפשר לשלב אותו בקריאות המתנה ולגרום ל‑wakeups ממוקדים.

מלכודת: FreeOnTerminate בהקשר של Service

בשירותים רואים לא פעם FreeOnTerminate := True. זה יכול לעבוד, אבל מקשה על שליטה ב‑Shutdown, כי לעיתים אין לך אז הפניה נקייה לחכות לסיום ה‑Thread ולרשום מצבי שגיאה. עבור לוגיקת Stop מבוקרת, לרוב יציב יותר להחזיק בבירור את ה‑Threads ולבצע בשלב ה‑Shutdown המתנה ודה‑אלוקציה דטרמיניסטית.

פעולות חוסמות: כך הופכים אותן לניתנות לעצירה

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

1) החלפת Sleep/Polling: Wait עם Stop-Event

אם אתה מפעיל עבודה תקופתית („לבדוק כל 10 שניות“), אל תשתמש ב-Sleep(10000), אלא המתן על Event עם Timeout. כך ה-Stop-Event יכול לסיים את ההמתנה מיד. זה מקטין את השיהוי של Stop ומונע את התחושה „השירות לא מגיב“.

2) Queue-Consumer: Work-Event + Stop-Event kombinieren

אם יש לך ארכיטקטורת Producer/Consumer (למשל Jobs מונחות בתור), אתה צריך אות שיעיר את ה-Consumer. בדרך כלל זהו TEvent נוסף (Work available). ה-Consumer מחכה אז על שני Handles: „Work“ או „Stop“. בעת Stop תפעיל את ה-Stop-Event ואם צריך גם את ה-Work-Event, כדי לוודא שכל ה-Consumer יוצאים מה-Wait.

3) Externe Calls (DB/HTTP): Timeouts und Abbruchpfade

בנקודות גישה למסד נתונים או ב-HTTP-Calls נקבעת היכולת של השירות לעצור בצורה נקיה. בשירות השוטף חלל הכלל: Kein Call ohne Timeout. Timeout אינו מותרות, אלא תנאי לניהול. בנוסף עליך לבדוק את ה-Stop בין שלבי Retries/Backoff. אחרת תקבל את הקלאסיקה: „Service stoppt nicht, weil er gerade 10 Retries mit Sleep macht“.

בחלק מהספריות ניתן לגרום לביטולים במפורש (למשל ביטול Query). אם זה לא אפשרי, עליך לפחות לקנפג Timeouts קצרים מספיק, כדי לא לפרוץ את ה-Shutdown-Timeout.

Stop Pending korrekt: Status, Logging und Erwartungsmanagement

כששירות עוצר, חשוב מבצעית להבין איפה הוא תקוע. לשם כך אתה צריך שני דברים:

• Log-Marker בנתיב ה-Stop: „בקשת Stop“, „אין עבודות חדשות“, „ממתין ל-Worker“, „Worker X הסתיים“, „ה-Shutdown הושלם“.
• זמנים ניתנים למדידה: כמה זמן לוקח ה-Stop? איזה שלב אוכל את הזמן? כאן לרוב מספיק מדד זמן מונוטוני כמו GetTickCount64 או TStopwatch (מונוטוני = לא מעוות על ידי שינויי זמן מערכת).

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

אילו לוגים מועילים באמת בשירותים?

• PID של השירות, זמן התחלה, גרסה/Build (ללא עומס מיותר).
• מספר Worker פעילים, מספר משימות בתעופה (in-flight).
• תלויות חיצוניות פעילות: «קריאת DB רצה», «HTTP-Request רץ», «Flush לקבצים רץ» (בצורה מאוגדת בלבד, לא כל פרט).
• הושג Stop-Timeout: אילו Worker עדיין פתוחים?

דיבוג בשטח: להפוך לניתן לשחזור במקום לנחש

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

לבחון את השירות במצב מבוקר

• עצירה במהלך עיבוד פעיל (לא בזמן Idle).
• עצירה בזמן תקלה חיצונית: DB לא נגיש לזמן קצר, נקודת קצה HTTP איטית, Fileshare חסר.
• עצירה מיד לאחר ההתחלה (תנאי מירוץ: Worker עדיין בבנייה).

Event Viewer und Service Control Manager Signale

Windows כותב אירועי שירות, אך אלה לעיתים קרובות גסים. עדיף שהשירות עצמו יכתוב לקובץ לוג או ליומן האירועים של Windows. חשוב: הרישום צריך להמשיך לפעול בנתיב העצירה. אם תשחרר את מנגנון הרישום מוקדם מדי בתהליך ה־shutdown או שה־Flush נחסם, תפסיד בדיוק את העקבות ההכרחיות.

להפוך Threads תקועים לנראים

אם אתה רואה שוב ושוב „Stop Timeout“, כדאי להסתכל על מצבי ה־Threads (למשל באמצעות Debugger/Procdump בסביבת בדיקה). לעתים קרובות תמצא Thread שנמצא במצב המתנה על Handle שאינו מוסר סימן לעולם, או בקריאת רשת ללא Timeout. התיקון בדרך כלל אינו „עוד Sleep“, אלא מסלול הפסקה מסודר.

מתי המאמץ באמת שווה את זה?

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

• השרות מעבד משימות עם השפעות לוואי (כתיבת קבצים, טרנזקציות DB, קריאות API).
• קיימים מספר Threads או Pool.
• השירות תלוי במשאבי רשת (DB, REST, Message Broker, Fileshares).
• התפעול דורש חלונות תחזוקה מתוכננים (Reboots, Updates, Failover).

הערך המוסף אינו „אלגנטיות“, אלא אמינות תפעולית: פחות קריסות תהליך קשות, פחות מצבים ביניים לא עקביים, פחות התערבויות ידניות.

מלכודות מעשיות: מה נוטה להשתבש ב־Shutdown

1) ה־Stop נקבע, אבל משימות חדשות עדיין נכנסות

אם אתה מקבל עבודה נכנסת (למשל דרך Socket, טריגר קובץ, Timer), עליך בנתיב העצירה קודם כל לעצור את קבלת העבודה החדשה: לסגור Listener, להשבית Timer, לעצור Scheduler. אחרת תרוץ אחרי הסיום כי משימות חדשות עדיין מתחילות.

2) ניקוי נחסם (Flush, Close, Finalize)

„פשוט לעשות Flush לכל דבר“ יכול להיות מסוכן בהקשר שירות אם היעד (כונן רשת, Remote-Log, DB) תקוע כרגע. לכן: ניקוי כן, אבל עם מגבלת זמן. במקרה הצורך תצטרך להחליט אילו נתונים תאבד בזיכרון במקום לחסום את העצירה כולה.

3) נעילות וסדר הפעולות

בעת עצירה אתה לעתים קרובות ניגש לאותן מבני נתונים כמו ה-Worker (Queues, Caches, States). אם ה-Stop-thread מחזיק Locks ואז ממתין לסיום ה-Worker, בעוד ה-Workers זקוקים לאותו Lock, נוצרת Deadlock של עצירה. אמצעי נגד: לשמור על זמני החזקת Lock קצרים, לא „להמתין תחת Lock“ בנתיב העצירה, ולהגדיר סדר ברור של נעילות.

4) מקביליות בעת עצירה כפולה

בעשייה המעשית עצירה יכולה להפעיל מספר פעמים (למשל Stop + Shutdown, או Stop שמגיע שוב). נתיב העצירה שלך צריך להיות idempotent: הגדרת Stop-Event בסדר, אך לוגיקה של Join/Free כפולה חייבת להיות מוגנת כהלכה (למשל באמצעות דגל אטומי).

מבט תפעולי: מה מנהלי מערכת ומנהלי IT מצפים מהשירות

בעבור התפעול והניהול בסופו של דבר לא נמדד עד כמה הקוד „יפה“, אלא האם השירות:

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

זו גם הסיבה לכך שנושא Stop-Timeout אינו רק „עניין של מפתחים“: הוא משפיע על מחזורי עדכונים (Patchzyklen), זמני שיקום והאם פריסות אוטומטיות בכלל אפשריות.

קווים מנחים קונקרטיים לעיצוב עצירה עמיד

אם ברצונך לתקנן את הנושא באופן פרגמטי, הקווים המנחים האלה הוכיחו את עצמם:

• אירוע עצירה גלובלי, Manual Reset, נוצר מוקדם במחזור חיי השירות ונשמר עד לשחרור מאוחר.
• אין Sleep בלולאות Worker בלי חלופה שתתמוך בעצירה (Wait עם Timeout).
• כל הקריאות החיצוניות עם Timeouts (DB, HTTP, Fileshares). לבחור Timeouts כך שיתאימו ל־Shutdown-Timeout שלך.
• Stop-Timeout כקונפיגורציה (למשל ב-INI/Registry), כדי שהתפעול יוכל להגיב ללא צורך בקומפילציה מחדש.
• מודל רב שלבי: קודם graceful (משימות רצות מסיימות), אחר כך אופציונלי „soft abort“ (אין התחלת צעדים חדשים), ואז יציאה חזקה כפתרון אחרון.
• לוגים טובים לעצירה עם שלבים ומדידת זמנים.

מסקנה: TEvent + Stop-Timeout זה לא מותרות, אלא יכולת שליטה

עצירה תקועה היא לעתים נדירות שגיאת בידוד — ברוב המקרים מדובר בחור בארכיטקטורה: עבודה רצה בתהליכים או בקריאות חוסמות שאין להן אות עצירה משותף. עם Stop-Event ברור (TEvent, Manual Reset), Waits התומכים בעצירה במקום Sleep, Timeouts עקביים לתלויות חיצוניות ו־Shutdown-Timeout מוגדר, תקבל שירות שניתן לחיזוי בתפעול היומיומי.

הקוד משתלם במיוחד כששירותך פועל בסביבת ייצור עם חלונות תחזוקה, פריסות אוטומטיות או תופעות לוואי קריטיות. אז „Graceful Shutdown“ אינו קוסמטיקה אלא רכיב לתפעול יציב ופחות הסלמות בעת אתחול הבא.

אם ברצונך להקים את נתיב העצירה שלכם כראוי או לבדוק שירות Delphi קיים ביחס ללוגיקת Shutdown רצינית ולבטיחות תפעולית, שיחת ייעוץ טכנית קצרה היא לעתים הדרך המהירה ביותר לצעדים ברורים: צרו קשר.

בנושא זה גם Delphi Windows Service ו-Tevent Delphi הם חשובים. המאמר מסדר את ההיבטים הללו בצורה מובנת ומראה על מה יש להישען בפועל.

לדון בפרויקט או במיזם מודרניזציה עם Net-Base.