Rust: Функции Rust, которые можно вызывать из C

Извините, что вмешался, но я хотел бы подчеркнуть, что вызов функций C должен быть быстрым, как в _blazing_ fast. Если я хочу написать игру в ржавчине с использованием библиотеки C, такой как Allegro, SDL или Opengl, это необходимо. В противном случае игра будет тормозить в коде рендеринга, где много вызовов C, что недопустимо. Компилятор языка Go по умолчанию с cgo имеет такие проблемы.

Поэтому я бы предпочел быстрое решение, даже если оно может ограничивать возможности функции на стороне Rust.

Кроме того, не было бы идеей использовать «native fn» вместо «crust fn» или это имеет другое запланированное значение?

@beoran, у вас это задом наперед. Мы говорим о том, что C вызывает Rust. Вызов функций C из Rust уже происходит довольно быстро (можно было бы сделать несколько быстрее).

Да я вижу. Могу ли я как-нибудь помочь ускорить вызов C из ржавчины?

@beoran, как я уже сказал, это как бы ортогонально этой проблеме ... но, вероятно, лучшее, что вы могли бы сделать, - это составить тест, показывающий, насколько производительность неадекватна. :)

Хорошо, я сделаю это, когда уйду достаточно далеко в обертке Allegro, чтобы сравнить накладные расходы на его вызов из rust Rust с вызовом из C. Я пока оставлю эту проблему в покое и открою новую, как только у меня будет эталон.

Можно ли избежать одной из копий аргументов, если функция C записывает непосредственно в стек Rust, как это делают в настоящее время вызовы Rust-> C?

Я надеюсь, что последняя копия аргументов из структуры оболочки и в аргументы функции ржавчины будет удалена путем встраивания. Я не уверен, что вы имеете в виду именно это.

Я считаю, что наши вызовы C в настоящее время копируют аргументы в структуру в стеке Rust, а затем копируют эту структуру в стек C.

@pcwalton Rust-> C в настоящее время не записывает напрямую в стек C, потому что это характерно для i386. Я хотел избежать написания кода, специфичного для конкретного соглашения о вызовах, даже ценой некоторой производительности, чтобы заставить работать 64-битную версию. (Я думаю, что сейчас такая оптимизация может иметь смысл - особенно, поскольку # 1402 указывает на то, что LLVM на самом деле не полностью обрабатывает соглашения о вызовах _ в любом случае_)

После чтения функции переключения стека структура arg вообще не копируется между стеками, указатель на предыдущий стек просто передается функции, которая выполняется в новом стеке, что имеет смысл.

Структура arg не копируется, но функция прокладки загружает из нее значения и повторно помещает их в новый стек. Старый код, используемый для буквальной записи значений аргументов непосредственно в целевой стек. Это имело смысл на i386, но на x86_64 гораздо сложнее выяснить, какие значения будут помещены в стек и т. Д.

После некоторого тестирования я обнаружил, что функциям crust будет очень сложно гарантировать, что они не откажутся. В настоящее время происходит то, что, когда задача верхнего уровня (например, main) терпит неудачу, каждой задаче сообщается, что она завершилась неудачей, поэтому, как только обратный вызов пытается отправить сообщение (или когда он возвращается после отправки сообщения), он может закончиться неудачей. и вызывая аварийное завершение выполнения.

Думаю, мы можем изменить rust_task, чтобы игнорировать запросы на уничтожение после того, как задачи снова попали в стек rust. Для задач, реализующих циклы событий, они могут заглянуть в какой-либо порт монитора в поисках сообщения, указывающего на сбой среды выполнения, и выяснить, как корректно завершить работу.

Итак, когда задача верхнего уровня терпит неудачу, она передает ошибки своим дочерним элементам? Думаю, я не понимаю нашу модель распространения ошибок, я думал, что она пошла с нуля. Кажется, что код, работающий в стеках C, должен иметь возможность запускаться в неконтролируемой задаче или что-то в этом роде.

По сути, он действует так, как будто "main" контролируется ядром, поэтому, если main не работает, все терпит неудачу.

Я называю это готовым. Есть небольшая очистка, и я зарегистрировал отдельные ошибки для оставшихся проблем.

Пожалуйста, простите это воскрешение, но эта проблема связана с y-комбинатором и несколькими другими сайтами, и недавно у меня был один нуб, спросивший об этом, поэтому я отмечаю, что в соответствии с этой проблемой и последующими изменениями, вызывая 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());
}