הבלוג של ארתיום

שפת C, פקודות goto, ניהול משאבים ומה שביניהם.

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

בשפות ללא destructorים כמו Java זה מאוד מקובל להשתמש בקטעי־try/finally לניהול משאבים. לדוגמה:

void function()
{
    resource r1,r2;
    try {
        r1.allocate()
        if(error1) throw;
        r2.allocate()
        if(error2) throw;
        do_something;
        if(error3) throw;
    }
    finally {
        r1.free();
        r2.free();
    }
}

למעשה, throw מקפיץ אותך לקטע finally שמאפשר שחרור מסודר של משאבים שלא מנוהלים ב־gc. עכשיו בואו נסתכל בקוד הבא:

void function()
{
    resource r1,r2;
    {
        r1.allocate()
        if(error1) goto filally;
        r2.allocate()
        if(error2) goto filally;
        do_something;
        if(error3) goto filally;
    }
    finally: {
        r1.free();
        r2.free();
    }
}

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

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

המשך...

לוותר על gc או לוותר על destructor?

היום, יש נטייה להשתמש בכל שפה אפשרית ב־GC – כי היא פותרת המון בעיות בניהול זיכרון. כמעט כל השפות פופולריות (למעט C/C++/Pascal) מממשות אותה בצורה זו או אחרת.

כמעט כולם (למעט CPython,‏ Perl ו־vala) משתמשות בשיטה של "בדיקת נגישות" (Reachability). בשיטה זו מנוע GC פועל אחת לזמן מה, מחפש כל מופעי אובייקטים שאינם נגישים יותר ומוחק אותם.

השיטה הפחות נפוצה, שמתשמשים בה למשל ב־CPython, היא שימוש ב"ספירת הפניות" (Reference counting), אבל היא קשה למימוש ובעייתית באופן כללי, בגלל טיפול בלולאות סגורות, כאשר אובייקט יכול להפנות לעצמו, ובכך "מספר הפניות" לעולם לא ירד מתחת ל־0.

שימוש ב־GC שיטה הראשונה פותרת את בעיית ניהול הזיכרון, יחד עם זו היא מציבה בעיה הגדולה אחרת: destructors או finalizers — מתודות שמבצעות "מחיקה" של האובייקט, הופכות לכמעט ולא רלוונטיות. כי אי אפשר לדעת מתי ישוחרר האובייקט. כלומר ב־Java, C#, IronPython, PHP, D וכמעט כל שפות אחרות שמשתמשות בשיטה הזו, destructors הם חסרי משמעות.

המשך...

על כלי פיתוח מהיר ועולם המחשוב

אחת הגישות המודרניות בפיתוח תכנה היא:

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

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

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

גם צורך בהעסקת כוח אדם מיומן היא משמעותית. כידוע, לא כל המתכנתים שווים. למשל, לפי נתוני indeed‏ ההבדל בין משכורת מפתח C++‎ לבין משכורת מפתח PHP או Asp.Net יכול להגיע עד פי־1.5–2.

השאלה היא, אם העיקרון הזה נכון והאם כדאי לצצד לו?

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

המשך...

תולדות הבלוג שלי (בעקבותיו של שלומי).

שלומי ישראל (הידוע כ־sijp) העביר לי משימה לכתוב בנושא "תולדות הבלוג שלי". בד"כ אני לא מתפתה להשתתף בשרשורי משימות כאלה, אבל הפעם, החלטתי שהנושא מספיק מעניין.

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

התכנון המקורי היה להתרכז בשני נושאים:

סלסה וריקוד ולהחליף פרסום כתבות באתר LaMusica.co.il‏‏ בכתיבה בבלוג שלי.
להתחיל לכתוב בנושא תכנה חופשית

לצערי, הנושא הראשון, בסופו של דבר, הסתכם במספר מצומצם של כתבות, כך שהבלוג הפך לבלוג מחשבים כמעט טהור; ובסביבות אוקטובר 2007, הוא זכה להיכנס ל־planet.linux.org.il‏.

במקביל התחלתי לפתח טכנולוגיית web חדשה — ‏CppCMS‏; ובדצמבר 2007, פתחתי בלוג נוסף באנגלית, שהיה אמור לשמש אותי לשתי מטרות:

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

יחד עם התקדמות הפרויקט, מערכת הבלוגים הפכה ליותר ויותר בשלה. במאי 2008 החלטתי להיפרד מוורדפרס ולהחליפו במערכת החדשה. מאד הבלוג הזה רץ על טהרת C++‎.

המשך...

הפתעה לא נעימה מ־MySQL.

אני יודע ש־MySQL זה לא בסיס נתונים מושלם, בעל מיליון ואחד פיצ'רים מעולים הדרושים לכל בסיס נתונים ארגוני. אבל יש לו יתרון אחר גדול… הוא מהיר מאוד, הרבה יותר מהיר מ־PostgreSQL ו־Sqlite3 (לפחות לפי הניסיון שלי).

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

חופש על "mysql shrink database" הביא אותי להבנה: לא ניתן לעשות כיווץ לטבלאות InnoDB, אלא אם אתה מגדיר ב־my.cnf, שכל טבלה תנוהל בקובץ נפרד‏:

[mysqld]
innodb_file_per_table

אבל איך לכווץ בסיסי נתונים קיימים? לא ניתן! אפשר לשמור dump של אותו בסיס נתונים. לשנות הגדרות mysql, למחוק את הקובץ ibdata1 באופן ידני ולייבא את הנתונים מקובץ קיים מחדש.

לאחר מכן, פעולה כמו:

optimize table xyz;

פשוט תעבדו לך, מחיקת בסיס נתונים תגרום למחיקת המידע מדיסק ואפילו delete from xyz;‎ תגרום לריקון הקובץ! למזלי, לא היו לי בסיסי נתונים יקרים (הכל היה לצורך ניסויים), כך שיכולתי פשוט למחוק אותם ולוותר על תהליך dump. עם כל זה המצב היה מאוד מאכזב:

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

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

המשך...

כשנגמר המקום ב־"/"

אתמול גיליתי שנגמר לי מקום בספריית "/" שאמורה להכיל כ־10G. כמובן ש־‎/home היא מחיצה נפרדת אבל עדיין… חסר לי מקום בצורה משמעותית.

כמובן, הדבר הראשון שמריצים במצב כזה apt-get clean שבד"כ משחרר אצלי כמה עשרות MB של מקום פנוי. אבל לאחר הפעולה הפשוטה הזו עדייו נשארו רק 150MB זמינים.

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

dpkg-query -W -f='${Installed-Size;10}\t${Package}\n' | sort -n

חשבתי, שהדברים הכבדים יהיו apache, mysql או כל מיני דברים מוסבכים אחרים שהתקנתי… אבל לא. זה היה הפלט (השורות האחרונות):

 69496      mingw32
 73428      valgrind
 76728      tetex-base
 82328      eclipse-platform-gcj
129740      openoffice.org-core
164304      openclipart-png
167892      ghc6
186672      openclipart-svg

חבילות כמו valgrind, tetex ו־OpenOffice ואפילו mingw32 משמשות אותי לעתים קרובות, כך שברור שהן יישארו.

openclipart די שימושי… אם כי במקרה הצורך אפשר לוותר עליו.

אבל: ghc6 – ‏Haskell? התקנתי אותו פעם, קמפלתי איתו משהו וזה פחות או יותר כל השימוש שהיה לי בו. eclipse? מעולם לא חשבתי שהוא מפלצת עד כדי כך! פעם התקנתי אותו, ניסיתי לעבוד איתו אבל די וויתרתי עליו כי הוא היה נורא כבד. והדבר הזה (+תלויות) תופס כל־כך הרבה מקום! אחרי שמחתי את שני הכלים האלה ואת התלויות שלהם, קיבלתי בחזרה כ־600MB…

למרות שאני עובד עם לינוקס המון זמן, אלה היו הפתעות גדולות, במיוחד Haskell שאני לא כתבתי בו אפילו שורת קוד אחת. מוסר השכל: "הכר את הכלים שלך. הם יעזרו לך בעת צורה (ולא רק)"

המשך...

צעד חשוב קדימה — ביזור של CppCMS.

למרות ש־CppCMS מצטיינת בביצועים גבוהים במיוחד, עדיין מגיע הרגע, בו צריך לבצע ביזור המערכת לצורך שיפור ביצועים. המערכת נבנתה מלכתחילה במחשבה שהיא תצטרך לרוץ על מספר מחשבים נפרדים, אבל היה חסר רכיב משמעותי אחרון — מערכת Cache מבוזרת.

עד היום CppCMS באה עם שתי אופציות של Cache‏ — משותף לחוטים של אותו תהליך (threaded) ומשותף לתהליכים שנוצרו ע"י מנגנון prefork (‏fork cache). לא היה ניתן לשתף Cache בין שני מחשבים שונים. לא הייתה בעיה עיקרונית להוסיף אותו, למעט העדר זמן הפיתוח.

ההכרות שלי עם ספריית Boost.Asio‏ פישטה את התהליכים בצורה משמעותית ואפשרה לי לממש את המודול החדש במהירות.

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

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

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

המודול מופעל ע"י שורת קונפיגורציה cache.backend="tcp"‎ ושני פרמטרים נוספים cache.ports ו־cache.ips המגדירים את רשימת הפורטים וכתובות ה־IP עליהם מאזינים שרתי ה־cache המבוזרים.

המשך...

פיתוח יישומי רשת ב־C++‎ או הצצה ל־Boost.Asio.

במאמר זה, אביא סקירה קצרה של ספריית Boost.Asio‏‏ – ספרייה לפיתוח יישומי תקשורת ב־C++‎ בצורה מהירה, יעילה ונוחה. ההכרות שלי איתה התחילה, דווקא מצורכי העבודה. אחרי זמן קצת, הבנתי שהיא מאוד נוחה ואפילו תהיה שימושית עבור CppCMS. למעשה, הספרייה הזו, אפשרה לי לעטוף את ספריית ה־cache של CppCMS ולהפוך אותה למבוזרת — לבנות פתרון בסגנון memcached — תוך מספר שעות בלבד.

הספרייה הזו קיימת בשתי גרסאות:

גרסת Boost.Asio: היא חלק מ־Boost החל מגרסתו 1.35.
גרסת Asio עצמאית, שדורשת Boost גרסה 1.33 ומעלה — מאפשרת לעשות שדרוג של ספרייה ללא תלות בגרסת Boost.

אחד המאפיינים המעניינים שלה היא העובדה, שהספרייה כולה כתובה על בסיס Template Metaprogramming ומהווה אוסף קובצי־"‎.hpp" בלבד.

"בעיית עשרת אלפים קשרים" או "למה צריך ספריות כאלה בכלל?"

מעבר לעובדה ש־Berkeley Sockets API‏ די מסובך, עדין ושונה במערכות הפעלה שונות — כבר סיבה מספיק טובה לבנות מעטפת עבורו — אני אתרכז דווקא במשהו אחר, כתיבת יישומים יעילים.

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

יש מספר גישות לבניית השרת:

המשך...

מתיאוריה למציאות, או עד כמה UTF-16 באמת בעייתי

בהמשך לפוסט הקודם, החלטתי לעשות סקירה קצרה: "האם באמת תכנות שכתובות עם utf-16 לא עובדות כמו שצריך עם קידודים כפולים ומה קורה עם תכנות שמשתמשות בייצוג פנימי ב־utf-8/utf-32?"

לקחתי תו "𠂊" או U+2008A וניסיתי להציג אותו ביישומים שונים מבוססים על toolkitים שונים. התו הזה מתייחס ל־CJK Unified Ideographs Extension B‏ ולא לא יכול להיות מיוצג ב־utf-16 בעזרת איבר אחד (שני בתים) אלא דורש צירוף של שני איברים (ארבעה בתים). אם אתם לא רואים את התו הזה, או רואים אותו כריבוע בדפדפן שלכם, אפשר להתקין גופן חופשי: AR PL ShanHeiSun Uni, בעלי דביאן יכולים להתקין חבילה ttf-arphic-uming.‏ חייב לציין, אין מי מושג מה התו או המילה האלה אומרים, כך שמתנצל מראש.

קודם כל: היישומים שעובדים עם utf-16 שהתמודדו אתו בצורה יפה ונכונה (או פשוט לא מצאתי באגים ב־2 דקות ששיחקתי איתם) הם:

OpenOffice שעובד עם icu (אם כי, אני לא בטוח שהוא משתמש בו בייצוג פנימי)
Microsoft Word עבד ללא בעיות ועובד עם Windows API המבוסס על utf16‏.
FreeMind שכתוב ב־Java הצליח להציג את התו ולערוך טקסט בצורה מסודרת. (Java משתמשת ב־utf-16 במחרוזות שלה).

אבל פה פחות או יותר נגמרו היישומים שעובדים עם utf-16 וגם מסתדרים עם התו הבעייתי. נתחיל:

המשך...

UTF-8, UTF-16, Unicode וכל מה שביניהם.

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

האנשים האלה חשבו וחישבו ששני בתים יספיקו לכסות את כל השפות אפשריות. כך נולד קידוד של Unicode בשני בתים. בתחילת ה־90, יצרתי UNIX הגדולים גם חשבו ובנו UTF-8 שכדי להבטיח תאימות לאחור עם כל התכנה הקיימת — כך נולד קידוד בעל אורך משתנה.

עבר הזמן, יצרני תכנה שונים הולכו בשני כיוונים: אחד להציג כל תו בשני בתים והשני להמשיך להשתמש ב־ANSI C String ולעבוד עם תווים בעלי ייצוג באורך שונה. אבל, באמצע שנות ה־90 כבר היה ברור ששני בתים לא יספיקו כדי לכסות את כל השפות האפשריות. ולכן התקן הורחב כך שהוא כלל ערכים מ־0 ועד ל־0x10FFFF.

המשך...