حدد () داخل حلقة لانهائية يستخدم بشكل كبير أكثر وحدة المعالجة المركزية على آلة RHEL 4.8 Virtual Virtual من آلة Solaris 10

Question

لدي تطبيق DAEMON مكتوب في C ويعمل حاليا مع عدم وجود مشكلات معروفة على جهاز Solaris 10. أنا في عملية نقله إلى لينكس. كان علي إجراء تغييرات ضئيلة. أثناء الاختبار يمر جميع حالات الاختبار. لا توجد مشاكل مع وظائفها. ومع ذلك، عندما أرى استخدام وحدة المعالجة المركزية الخاصة به عند تشغيل "الخمول" على جهاز Solaris الخاص بي، فإنه يستخدم حوالي .03٪ CPU. على الجهاز الظاهري تشغيل Red Hat Enterprise Linux 4.8 هذه العملية تستخدم كل وحدة المعالجة المركزية المتاحة (عادة ما تكون في مكان ما في نطاق 90٪ +).

كان فكرتي الأولى أن شيئا ما يجب أن يكون خطأ في حلقة الحدث. حلقة الحدث هي حلقة لا حصر لها (while(1)) مع مكالمة ل select(). وبعد timeval هو الإعداد بحيث timeval.tv_sec = 0 و timeval.tv_usec = 1000. وبعد هذا يبدو معقولا بما فيه الكفاية لما تفعله العملية. كاختبار أصفرت timeval.tv_sec إلى 1. حتى بعد القيام بذلك رأيت نفس المشكلة.

هل هناك شيء أفتقده حول كيفية اختيار Works على Linux مقابل UNIX؟ أو هل يعمل بشكل مختلف مع وجدارة نظام التشغيل على جهاز افتراضي؟ أو ربما هناك شيء آخر أفتقده بالكامل؟

شيء آخر أنا لست متأكدا من استخدام إصدار خادم VMware. تم تحديثه للتو منذ حوالي شهر.

Answer 1

أعتقد أن Linux إرجاع الوقت المتبقي عن طريق كتابة ذلك في الوقت الحالي للاتصال المحدد () و Solaris لا. هذا يعني أن مبرمج لا يدرك المواصفات بوسيكس قد لا يؤدي إلى إعادة تعيين المعلمة الزمنية بين المكالمات لتحديد.

من شأنه أن يؤدي ذلك إلى أول مكالمة لها 1000 مهلة USEC وجميع المكالمات الأخرى باستخدام 0 USEC Timeout.

Answer 2

كما قال زان لينكس، يتم تعديل Timeval عن طريق تحديد على Linux، لذلك يجب عليك إعادة تعيين القيمة الصحيحة قبل أن تحدد كل مكالمة. كما أقترح التحقق مما إذا كان بعض واصف الملفات في حالة معينة (مثل نهاية الملف، وأغلق اتصال الأقران ...). ربما يقوم Porting بإظهار بعض الخلل الكامن في تبجيل القيم المرتجعة (fd_isset وما إلى ذلك). حدث لي منذ بضع سنوات منذ بضع سنوات في ميناء دورة محددة: كنت أستخدم القيمة التي تم إرجاعها بطريقة خاطئة، وأضاف FD مغلق إلى RD_Set، مما يؤدي إلى فشل تحديد. على النظام الأساسي القديم، تم استخدام FD الخطأ للحصول على قيمة أعلى من MAXFD، لذلك تم تجاهلها. بسبب نفس الخطأ، لم يتعرف البرنامج على فشل تحديد (حدد () == -1) ولقر إلى الأبد.

وداعا!