הקדמה

מערכות הפעלה מודרניות, כפי שכולנו יודעים, מאפשרות ביצוע של מספר פעולות במקביל. ב-Windows לדוגמא, אנחנו יכולים להריץ מספר תוכניות ולעבור ביניהן. כל תוכנית כזו שרצה בנפרד נקראת תהליך (process). מבלי להכנס יותר מדי למה שעושה מערכת ההפעלה, נגיד רק שתהליך הוא יחידת הרצה עצמאית - יש הפרדה ברורה בין מה שנמצא 'בתוך' ו-'שייך' לתהליך, לבין כל מה שלא. את ההפרדה הזו אוכפת מערכת ההפעלה: לדוגמא, קוד שרץ בתהליך מס. 1000 לא יכול (באופן ישיר) להתערב בנתונים ובפעולות שרצות בתהליך מס. 2000. חשוב להבין שהפעלת תהליך הוא דבר 'כבד' יחסית ודורש משאבים רבים ממ'ה.
כמו כן, ניתן לבצע מספר פעולות במקביל בתוך תהליך אחד (למשל, העתקה של קובץ גדול ובמקביל עדכון progress bar על התקדמות). כל פעולה כזו מתבצעת בתוך ישות שנקראת נים (thread). לכל הנימים בתהליך אחד יש גישה לאותם נתונים ואותו מרחב זיכרון. שימוש במספר נימים דורש פחות משאבי מערכת מאשר שימוש במספר תהליכים, אבל הוא מסובך יותר: יש להביא בחשבון סינכרון בין נימים שונים, לוודא שאין נעילות הדדיות בין נימים ועוד אוסף בעיות שונות. שליטה בתכנות עם מספר נימים (multi-threaded programming) נחשבת - ובצדק - לרמת שליטה גבוהה.
למען השלמות, נזכיר מנגנון שלישי שנקרא סיבים (Fibers) וקשור לנימים. במאמר זה לא נפרט לגביו.


מהם AppDomains?

ראינו שמערכת ההפעלה מספקת יכולות הרצה במקביל בצורה של תהליכים ושל נימים. כאשר יצא ה-Net. Framework, מיקרוסופט הציעו יכולת נוספת להרצה במקביל שנקראת Application Domains (או בקיצור, AppDomains). למעשה, AppDomain הוא תהליך 'לוגי', בניגוד לתהליך 'פיזי' של מערכת ההפעלה. המשמעות המעשית היא שמערכת ההפעלה תריץ רק תהליך אחד (ותבצע הקצאת משאבים רק עבור תהליך אחד), בעוד שה-Framework יעשה שימוש באותו תהליך בודד להרצת מספרAssemblies (קבצים בינאריים של NET., בעלי סיומת dll או exe). היות וה-CLR (מנוע הריצה של ה-Framework) יודע לאיזה זכרון ניגש כל assembly (למעט מקרים של קוד שמשתמש בפעולות שמוגדרות unsafe, מצב שנתעלם ממנו כרגע) הרי שביכולתו למנוע התנגשויות בין assemblies שונים
ולהפעיל כל אחד מהם כאילו היה בתהליך משל עצמו.
לכל תהליך שמפעיל את ה-CLR (כלומר כל פעם שמריצים תוכנית שנכתבה בשפת NET. כלשהיא) נוצר AppDomain ראשי שנקרא Default AppDomain. במידה ולתוכנית יש הרשאות מתאימות, אזי ביכולתה ליצור ולמחוק AppDomains אחרים, ולהריץ בתוכם קוד. אלא אם כן התוכנית יוצרת AppDomains חדשים, כל הקוד בתוכנית ירוץ ב-default AppDomain
היתרונות של שימוש ב-AppDomains נפרדים הם בין היתר:

• שימוש בפחות משאבי מערכת (פחות תהליכים)
• ניתן להפעיל ולעצור אפליקציה ב-AppDomain אחד מבלי להשפיע על אפליקציות ב-AppDomain אחר
• שגיאות ו-Exceptions ב-AppDomain אחד לא משפיעות על AppDomain אחר
• לכל AppDomain ניתן לתת הגדרות אבטחה בנפרד
• קוד ב-AppDomain אחד לא יכול להשפיע באופן ישיר על קוד ב-AppDomain אחר
  

למה זה טוב?

נראה כעת מספר דוגמאות לשימוש יעיל ב-AppDomains:

בדוגמא הראשונה, נחשוב על מערכת להגשה אוטומטית של תרגילי תכנות. המרצה/מורה חילק תרגיל תכנותי, ועל התלמידים להגיש קובץ exe שמבצע את המטלה. אם המורה פשוט יריץ את ה-exe, הרי שהתלמידים יוכלו לעשות במחשב מה שירצו - למחוק קבצים וספריות, לקרוא כל קובץ שירצו, וכו'. במערכת שמשתמשת ב-AppDomains, המורה ישתמש ב-Default AppDomain כדי להוריד את
ה-exe מהדוא'ל וליצור AppDomain חדש שבו לדוגמא לתוכנית מותר לקרוא רק מספרייה מסויימת, אסור לה לכתוב לשום מקום או לגשת לרשת, וכו'. בתוך ה-AppDomain החדש ירוץ קובץ ה-exe שהגיע מהתלמיד. כמו כן, אם מדובר בתוכניות שצריכות לרוץ זמן רב, ניתן ליצור מספר AppDomains מוגבלים ולהריץ כמה תוכניות ביחד. שגיאה בתוכנית של תלמיד אחד לא תשפיע על תוכניות של תלמידים אחרים.
בדוגמא השנייה, נסתכל על מימוש אמיתי - סביבת ה-ASP.NET של מיקרוסופט. זהו תהליך פיזי של מערכת ההפעלה (שנקרא aspnet.exe) אשר משמש כמארח (host) של ה-CLR. כל web application שמוגדר ל-ASP.NET יקבל AppDomain לעצמו. אם מתרחשת שגיאה כלשהיא באפליקצה אחת אז אין שום השפעה על אפליקציות אחרות על אותו שרת. כמו כן, המארח מספיק חכם כדי 'למחזר' AppDomains שרצים זמן ארוך מדי או צורכים יותר מדי זכרון, ובצורה כזו לשמור על ביצועים טובים. לבסוף, אם מעדכנים הגדרות של web application כלשהוא תוך כדי ריצה, הרי שגם כאן המארח חכם מספיק למחזר את ה-AppDomain המתאים ולהעלות את האפליקציה מחדש (עם ההגדרות החדשות כמובן).


סיכום

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

להלן דוגמת קוד לשימוש ב-AppDomains. יש לקמפל את הקוד לתוך exe ולהריץ. התוכנית סופרת מ-0 עד 9, פעם ב-Default AppDomain ופעם ב-AppDomain שנוצר באופן מפורש. שתי נקודות לתשומת לבכם:

1. את היצירה, מחיקה והרצת הקוד ב-AppDomain החדש אנחנו עושים בתוך בלוק של try..finally. הסיבה היא שבגלל שהפעלנו את הקוד מתוך ה-Default AppDomain, כל exception שנזרק מתוך ה-AppDomain החדש יגיע אלינו. על מנת להריץ קוד נפרד לחלוטין יש לעשות את זה דרך ה-CLR Host, וזה נושא מורכב הרבה יותר.
2. שימו לב למחיקת ה-AppDomain בסוף - ניתן למחוק רק AppDomain מלא ולא Assemblies ספציפים בתוכו.

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

קוד:

  
using System;

using System.Collections.Generic;

using System.Text;

using System.Reflection;

namespace AppDomainSample

{

classProgram

{

staticvoid Main(string[] args)

{

// This code only runs in the default AppDomain

if (AppDomain.CurrentDomain.IsDefaultAppDomain())

{

AppDomain newAppDomain = null;

try

{

// Create a new AppDomain

newAppDomain = AppDomain.CreateDomain("new AppDomain");

// Run this assembly in the new AppDomain

newAppDomain.ExecuteAssemblyByName(

Assembly.GetExecutingAssembly().FullName);

}

finally

{

// Delete the new AppDomain

if(newAppDomain != null)

AppDomain.Unload(newAppDomain);

}

}

// Do some work, and write in which AppDomain it runs

for (int i = 0; i < 10; i++)

{

Console.WriteLine("Number {0} in AppDomain {1}",

i, AppDomain.CurrentDomain.FriendlyName);

}



}

}

}

 

דורון

כל הכבוד על ההשקעה!.
רק יש לי שאלה שלא ברורה לי. בהתחלה דיברת על EXE שרץ אצל מישהוא, ואחרי זה דיברת על שרת. אז לא ברור לי עם זה עובד גם בשרת וEXE, או רק שרת או רק EXE...

ויש לי עוד שאלה, כאשר תוכנה מנסה ליכתוב בכל זאת במקום אסור, מה קורה? מי עוצר אותה? ה-Framework עצמו? ומה מונע מן התוכנה לשנות את ההגדרות?
ושוב, כל הכבוד

אנסה לענות על השאלות, אנא תקן אותי אם לא הבנתי מה שאלת:

1. ASP.Net הוא בעצם תוכנית exe בעצמו שמורץ מתוך ה-IIS ומשתמש ב-CLR. לכן, הוא יכול להשתמש ב-AppDomains. למעשה, בכלל לא מעניין אותו שמי שמריץ אותו הוא שרת Web. גם ב-SQL Server 2005 יש שימוש ב-CLR ו-AppDomains בתוך שרת בסיס הנתונים.
2. מי שעוצר אותה זה ה-CLR (וראה את המאמרים על CAS). מה שקורה הוא שמקבלים SecurityException. התוכנית לא יכולה לשנות את ההגדרות של עצמה, כי ה-CLR לא מאפשר לה לעשות את זה. ניתן להגדיר מדיניות אבטחה פעם אחת בלבד, בעת שה-App Domain נוצר. ל-Default AppDomain מי שעושה את זה הוא ה-CLR Host (למשל, Asp.Net) ול-AppDomains שאינם Default מי שעושה את זה הוא המתכנת שיוצר את ה-AppDomains.

1. הבנתי. תודה
2. בסופו של דבר תוכנה מגדירה את זה. אז מה מונע ממנו ליקרא לתוכנית אחרת או להשתמש ברכיב של מערכת ההפעלה או משהוא כזה?

1. בכיף. תבוא כל יום...
2. שאלה מצויינת, והתשובה היא בשני חלקים. לגבי קריאה לתכנית אחרת - אם התכנית כתובה בשפת Net. כלשהיא (managed code) אז מנגנון ה-stack walk של ה-Framework יוודא שלא תוכל להריץ אותה (מתואר בחלק השני של המאמר על CAS). אם התוכנית היא unmanaged code, אז תצטרך להפעיל אותה עם Process.Start - ולכך אתה צריך הרשאות מתאימות.
לגבי קריאה למערכת ההפעלה - אתה למעשה מדבר על P\Invoke, שזה מנגנון הקריאה הישירה לקוד שהוא unmanaged. גם לזה אתה צריך הרשאות מתאימות. כך שאם הגדרת מדיניות אבטחה שאוסרת על כתיבת קבצים אבל מרשה קריאה ל-Win32 API, אז די ירית לעצמך ברגל... ה-Framework נותן לך הרבה חבל, אבל לא תמיד יכול להבטיח שלא תתלה את עצמך בעזרתו.
Hope that helps

אוקי!. תודה!