العمليات متعددة الخيوط و close()¶

من غير الحكيم على الأرجح إغلاق واصفات الملفات بينما قد تكون قيد الاستخدام بواسطة استدعاءات نظام في خيوط أخرى في نفس العملية. نظرًا لأن واصف الملف قد يُعاد استخدامه، فهناك بعض حالات السباق المبهمة التي قد تسبب آثارًا جانبية غير مقصودة.

علاوة على ذلك، اعتبر السيناريو التالي حيث يؤدي خيطان عمليات على نفس واصف الملف:

(1)

خيط واحد محظور في استدعاء نظام إدخال/إخراج على واصف الملف. على سبيل المثال، يحاول write(2) إلى أنبوب ممتلئ بالفعل، أو يحاول read(2) من مقبس دفق لا يحتوي حاليًا على بيانات متاحة.

(2)

يغلق خيط آخر واصف الملف.

يختلف السلوك في هذه الحالة عبر الأنظمة. في بعض الأنظمة، عند إغلاق واصف الملف، يعود استدعاء النظام المحظور فورًا بخطأ.

في لينكس (وربما بعض الأنظمة الأخرى)، يختلف السلوك: يحتفظ استدعاء نظام الإدخال/الإخراج المحظور بمرجع لوصف الملف المفتوح الأساسي، ويبقي هذا المرجع الوصف مفتوحًا حتى يكتمل استدعاء نظام الإدخال/الإخراج. (انظر open(2) لمناقشة أوصاف الملفات المفتوحة.) وبالتالي، قد يكتمل استدعاء النظام المحظور في الخيط الأول بنجاح بعد close() في الخيط الثاني.

التعامل مع إرجاعات الخطأ من close()¶

سيتحقق المبرمج الحذر من القيمة المُرجعة لـ close()، لأنه من المحتمل جدًا أن تُبلغ الأخطاء في عملية write(2) سابقة فقط عند close() النهائي الذي يحرر وصف الملف المفتوح. قد يؤدي الفشل في التحقق من القيمة المُرجعة عند إغلاق ملف إلى فقدان صامت للبيانات. يمكن ملاحظة هذا بشكل خاص مع NFS وحصة القرص.

لاحظ، مع ذلك، أن الإرجاع الفاشل يجب استخدامه فقط لأغراض تشخيصية (أي تحذير للتطبيق بأنه قد لا يزال هناك إدخال/إخراج معلق أو قد يكون هناك إدخال/إخراج فاشل) أو أغراض علاجية (مثل كتابة الملف مرة أخرى أو إنشاء نسخة احتياطية).

إعادة محاولة close() بعد إرجاع فاشل هو الشيء الخطأ فعله، لأن هذا قد يتسبب في إغلاق واصف ملف مُعاد استخدامه من خيط آخر. يمكن أن يحدث هذا لأن نواة لينكس دائمًا تطلق واصف الملف مبكرًا في عملية الإغلاق، وتحرره لإعادة الاستخدام؛ الخطوات التي قد تُرجع خطأ، مثل مسح البيانات إلى نظام الملفات أو الجهاز، تحدث فقط لاحقًا في عملية الإغلاق.

تغلق العديد من التطبيقات الأخرى بالمثل واصف الملف دائمًا (باستثناء حالة EBADF، مما يعني أن واصف الملف كان غير صالح) حتى لو أبلغت لاحقًا عن خطأ عند العودة من close(). كان POSIX.1-2008 صامتًا بشأن هذه النقطة.

يمكن للمبرمج الحذر الذي يريد معرفة أخطاء الإدخال/الإخراج أن يسبق close() باستدعاء fsync(2).

خطأ EINTR هو حالة خاصة إلى حد ما. بخصوص خطأ EINTR، قال POSIX.1-2008:

يسمح هذا بالسلوك الذي يحدث في لينكس والعديد من التطبيقات الأخرى، حيث، كما هو الحال مع الأخطاء الأخرى التي قد تُبلغ عنها close()، يُضمن إغلاق واصف الملف. ومع ذلك، يسمح أيضًا بإمكانية أخرى: أن يُرجع التطبيق خطأ EINTR ويبقي واصف الملف مفتوحًا. (وفقًا لوثائقه، يفعل close() في HP-UX هذا.) يجب على المستدعي بعد ذلك استخدام close() مرة أخرى لإغلاق واصف الملف، لتجنب تسرب واصفات الملفات. يوفر هذا الاختلاف في سلوكيات التطبيق عقبة صعبة للتطبيقات المحمولة، لأنه في العديد من التطبيقات، لا يجب استدعاء close() مرة أخرى بعد خطأ EINTR، وفي تطبيق واحد على الأقل، يجب استدعاء close() مرة أخرى.

وحد POSIX.1-2024 سلوك HP-UX، مما جعل لينكس والعديد من التطبيقات الأخرى غير متوافقة. لا توجد خطط لتغيير السلوك في لينكس.