Rust: Funciones de Rust que se pueden llamar desde C

Lamento saltar aquí, pero me gustaría enfatizar que llamar a las funciones de C debe ser rápido, como en _brillante_ rápido. Si quiero escribir un juego en rust usando una biblioteca C como Allegro, SDL u Opengl, esto es esencial. De lo contrario, el juego se ralentizará en el código de renderizado donde hay muchas llamadas C, lo cual es inaceptable. El compilador de lenguaje Go predeterminado con cgo tiene tales problemas.

Por lo tanto, preferiría una solución que sea rápida, aunque puede restringir lo que puede hacer la función en el lado de Rust.

Además, ¿no sería una idea usar "native fn" en lugar de "crust fn" o eso tiene otro significado planeado?

@beoran tienes esto al revés. Estamos hablando de C llamando a Rust. Llamar a funciones C desde Rust ya es bastante rápido (podría hacerse algo más rápido).

OK veo. ¿Hay alguna forma de que pueda ayudar a acelerar las llamadas a C desde el óxido?

@beoran, como dije, es un poco ortogonal a este problema ... pero probablemente lo mejor que podría hacer es hacer un punto de referencia que muestre cómo el rendimiento es inadecuado. :)

De acuerdo, lo haré cuando llegue lo suficientemente lejos en envolver Allegro para comparar la sobrecarga de llamarlo desde rust Rust con llamarlo desde C. Dejaré este problema solo por ahora y abriré uno nuevo una vez que tenga el punto de referencia.

¿Podríamos evitar una de las copias de los argumentos haciendo que la función C escriba directamente en la pila de Rust, como lo hacen actualmente las llamadas a Rust-> C?

Espero que la copia final de los argumentos fuera de la estructura shim y dentro de los argumentos de la función rust se elimine mediante la inserción. Sin embargo, no estoy seguro de si eso es a lo que te refieres.

Creo que nuestras llamadas de C actualmente copian los argumentos en una estructura en la pila de Rust y luego copian esa estructura en la pila de C.

@pcwalton Rust-> C actualmente no escribe directamente en la pila de C porque es específico de i386. Quería evitar tener que escribir código que fuera específico de una convención de llamada en particular, incluso al precio de un poco de rendimiento, para que el funcionamiento de 64 bits funcione. (Creo que tales optimizaciones podrían tener sentido ahora, sin embargo, particularmente porque el # 1402 señala que LLVM realmente no maneja las convenciones de llamadas por completo _ de todos modos_)

Después de leer la función de cambio de pila, la estructura arg no se copia en absoluto entre las pilas, el puntero a la pila anterior simplemente se pasa a la función que se ejecuta en la nueva pila, lo que tiene mucho sentido.

La estructura arg no se copia, pero la función shim cargará valores y los volverá a enviar a la nueva pila. El código antiguo utilizado para escribir literalmente los valores de los argumentos directamente en la pila de destino. Esto tenía sentido en i386 pero en x86_64 es mucho más complejo averiguar qué valores irán a la pila, etc.

Después de algunas pruebas, descubrí que será muy difícil para las funciones de corteza garantizar que no fallan. Lo que sucede actualmente es que, cuando una tarea de nivel superior (como la principal) falla, se le dice a cada tarea que falle, por lo que tan pronto como la devolución de llamada intenta enviar un mensaje (o cuando regresa de enviar un mensaje) puede terminar fallando. y provocando que el tiempo de ejecución se anule de forma anormal.

Supongo que podemos cambiar rust_task para ignorar las solicitudes de eliminación una vez que las tareas hayan vuelto a entrar en la pila de óxido. Para las tareas que implementan bucles de eventos, pueden echar un vistazo a algún puerto de monitor en busca de un mensaje que indique que el tiempo de ejecución está fallando y averiguar cómo terminar correctamente.

Entonces, cuando una tarea de nivel superior falla, ¿propaga los errores a sus hijos? Supongo que no entiendo nuestro modelo de propagación de errores, pensé que iba de las hojas hacia arriba. Parece que el código que se ejecuta en pilas C debería poder ejecutarse en una tarea no supervisada o algo así.

Básicamente actúa como si 'main' estuviera supervisado por el kernel, por lo que si main falla, todo falla.

Estoy llamando a esto hecho. Hay una pequeña limpieza y he presentado errores por separado para los problemas restantes.

Por favor, perdone esta resurrección, pero este problema está vinculado desde una pieza de combinador y y algunos otros sitios, y recientemente un novato me preguntó al respecto, así que estoy notando que, según este problema y cambios posteriores, llamo a Rust desde C es simple :

#[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());
}