Rust: وظائف الصدأ التي يمكن استدعاؤها من C.

آسف للقفز هنا ، لكني أود التأكيد على أن استدعاء وظائف C يجب أن يكون سريعًا ، كما هو الحال في _blazing_ fast. إذا كنت أرغب في كتابة لعبة في الصدأ باستخدام مكتبة C مثل Allegro أو SDL أو Opengl ، فهذا ضروري. وإلا فإن اللعبة ستتباطأ في رمز العرض حيث يوجد الكثير من مكالمات C ، وهو أمر غير مقبول. مترجم لغة Go الافتراضي مع cgo لديه مثل هذه المشاكل.

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

أيضًا ، ألن تكون فكرة استخدام "أصلي fn" بدلاً من "crust fn" أم أن هذا له معنى مخطط آخر؟

beoran لديك هذا إلى الوراء. نحن نتحدث عن C استدعاء Rust. يعد استدعاء وظائف C من Rust سريعًا بالفعل (يمكن جعله أسرع إلى حد ما).

حسنًا ، فهمت. هل هناك أي طريقة يمكنني من خلالها تسريع استدعاء C من الصدأ؟

beoran كما قلت ، إنه نوع من التعامد لهذه المشكلة ... ولكن ربما يكون أفضل شيء يمكنك القيام به هو وضع معيار يوضح كيف أن الأداء غير ملائم. :)

حسنًا ، سأفعل ذلك عندما أقوم بلف Allegro بعيدًا بما يكفي لمقارنة النفقات العامة لاستدعائها من الصدأ Rust باستدعاءها من C. سأترك هذه المشكلة بمفردها في الوقت الحالي وسأفتح واحدة جديدة بمجرد المؤشر.

هل يمكننا تجنب إحدى نسخ الوسائط من خلال جعل الدالة C تكتب مباشرة إلى مكدس Rust ، كما تفعل استدعاءات Rust-> C حاليًا؟

آمل أن يتم التخلص من النسخة النهائية من الحجج من هيكل الرقائق إلى حجج وظيفة الصدأ من خلال التضمين. لست متأكدًا مما إذا كان هذا هو ما تشير إليه.

أعتقد أن مكالمات C الخاصة بنا تقوم حاليًا بنسخ الحجج إلى بنية على مكدس Rust ثم نسخ هذا الهيكل إلى المكدس C.

pcwalton Rust-> C لا تكتب حاليًا مباشرة في مكدس C لأن ذلك خاص بـ i386. أردت تجنب الاضطرار إلى كتابة رمز خاص باتفاقية اتصال معينة ، حتى بسعر بعض الأداء ، من أجل الحصول على عمل 64 بت. (أعتقد أن مثل هذه التحسينات قد تكون منطقية الآن ، على الرغم من - خاصة وأن # 1402 يشير إلى أن LLVM لا تتعامل حقًا مع اصطلاحات الاستدعاء تمامًا _ بأي حال_)

بعد قراءة وظيفة تبديل المكدس ، لا يتم نسخ بنية الوسيطة عبر المكدس على الإطلاق ، ويتم تمرير المؤشر إلى المكدس السابق للتو إلى الوظيفة التي تعمل على المكدس الجديد ، وهو أمر منطقي تمامًا.

لم يتم نسخ بنية arg ، لكن دالة الرقائق ستحمل قيمًا منه وتعيد دفعها إلى المكدس الجديد. الكود القديم المستخدم لكتابة قيم الوسيطات حرفيًا مباشرة في المكدس الهدف. كان هذا منطقيًا في i386 ولكن في x86_64 ، يكون الأمر أكثر تعقيدًا لمعرفة القيم التي سيتم وضعها في المكدس وما إلى ذلك.

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

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

إذن ، عندما تفشل مهمة المستوى الأعلى ، فإنها تنشر أخطاء لأبنائها؟ أعتقد أنني لا أفهم نموذج انتشار الخطأ الخاص بنا ، اعتقدت أنه ذهب من الأوراق لأعلى. يبدو أن الكود الذي يعمل على C Stacks يجب أن يكون قادرًا على العمل في مهمة غير خاضعة للإشراف أو شيء من هذا القبيل.

إنه يتصرف بشكل أساسي كما لو أن النواة تشرف على "main" ، لذلك إذا فشل main في فشل كل شيء.

أنا أسمي هذا انتهى. هناك القليل من التنظيف ، وقد قدمت أخطاء منفصلة للمشكلات المتبقية.

أرجو أن تغفر هذه القيامة ، لكن هذه المشكلة مرتبطة بقطعة y-combinator وبعض المواقع الأخرى ، وقد كان لدي مؤخرًا مستجد يسأل عنها ، لذلك أنا أشير إلى أنه في هذه المسألة والتغييرات اللاحقة ، اتصل بـ Rust من C بسيط :

#[no_mangle]
pub extern fn hello_rust() -> *const u8 {
    "Hello, world!\0".as_ptr()
}

#include "stdio.h"
const char *hello_rust(void);
int main(void) {
    printf("%.32s\n", hello_rust());
}