كمتابعة للرقم 1433 ، أفترض أن المكون الإضافي mmap قد تأثر أيضًا. على سبيل المثال ، لنفترض أن $ HOME يتغير وأن ملف التكوين الجديد أقدم أيضًا من ملف ذاكرة التخزين المؤقت mmap. ثم سيتم أخذ ملف ذاكرة التخزين المؤقت على الرغم من أنه قديم بالفعل.
لا أتوقع أنه يمكننا إصلاح ذلك بسهولة ، لكن سيكون من الجيد أن تصف المتطلبات التي لدينا والتي لا تحدث مثل هذه المشكلات.
أنت على حق ، ذاكرة التخزين المؤقت حاليًا تتحقق فقط من ENV في الملحقات kdbOpen. يمكن فحصه بسهولة ديناميكيًا ، لكن هذا يستدعي المحلل وأظن أن له بعض التأثير على الأداء.
تحرير: في ملاحظة جانبية: يتم فحص التهيئة للحصول على الطابع الزمني الدقيق (دقة nanosec) ، ولكن المشكلة لا تزال قائمة وهي صحيحة بالنسبة للمحلل الافتراضي أيضًا.
الحل البديل لهذا الخطأ هو أننا نقوم أيضًا بتخزين أسماء الملفات التي تم حلها داخل ذاكرة التخزين المؤقت mmap. ولكن بشكل عام لن يساعد ذلك ، سنحتاج بطريقة ما إلى التقاط جميع المتغيرات التي قد يكون لها تأثير (أو تجنب استخدام أي متغير بيئة داخل المكونات الإضافية ، والذي قد يكون الحل الأكثر أناقة على أي حال).
لم أفكر في هذا السيناريو ، لكننا في الواقع نقوم بتخزين اسم الملف الذي تم حله داخل ذاكرة التخزين المؤقت mmap. إذا تغير المسار ، فسوف ينتج عنه خطأ في ذاكرة التخزين المؤقت.
ومع ذلك ، إذا تغير $ HOME أثناء فتح مقبض KDB ، فلن يتم نقل ذاكرة التخزين المؤقت إلى المنزل الجديد.
لم أفكر في هذا السيناريو ، لكننا في الواقع نقوم بتخزين اسم الملف الذي تم حله داخل ذاكرة التخزين المؤقت mmap. إذا تغير المسار ، فسوف ينتج عنه خطأ في ذاكرة التخزين المؤقت.
ممتاز! هذه هي القضية الأكثر أهمية على أي حال. Afaik حاليا ليس لدينا متغيرات البيئة باستثناء المحلل. (ليست كل متغيرات البيئة لها تأثير فعلي على اسم الملف ، على الرغم من ذلك. يستخدم curlresolver HTTP_PROXY.)
ومع ذلك ، إذا تغير $ HOME أثناء فتح مقبض KDB ، فلن يتم نقل ذاكرة التخزين المؤقت إلى المنزل الجديد.
حسنًا ، لكن هذا خطأ قديم (# 1433). لذلك سوف أقوم بإغلاق هذا الخطأ حيث يبدو أن mmap لا يجعل الوضع أسوأ.