Rust: Rust-Funktionen, die von C aus aufgerufen werden können

Es tut mir leid, hier einzuspringen, aber ich möchte betonen, dass das Aufrufen von C-Funktionen schnell sein sollte, wie in _blazing_ fast. Wenn ich ein Spiel in Rust mit einer C-Bibliothek wie Allegro, SDL oder Opengl schreiben möchte, ist dies unerlässlich. Andernfalls wird das Spiel im Rendering-Code verlangsamt, wenn es viele C-Aufrufe gibt, was inakzeptabel ist. Der standardmäßige Go-Sprachcompiler mit cgo hat solche Probleme.

Daher würde ich eine schnelle Lösung bevorzugen, auch wenn sie möglicherweise die Möglichkeiten der Funktion auf der Rust-Seite einschränkt.

Wäre es nicht auch eine Idee, "native fn" anstelle von "crust fn" zu verwenden, oder hat das eine andere geplante Bedeutung?

@beoran Sie haben das rückwärts. Wir sprechen über C, das Rust anruft. Das Aufrufen von C-Funktionen aus Rust ist schon ziemlich schnell (könnte etwas schneller gemacht werden).

OK, ich verstehe. Gibt es eine Möglichkeit, wie ich das Anrufen von C aus Rost beschleunigen kann?

@beoran wie gesagt, es ist irgendwie orthogonal zu diesem Problem ... aber wahrscheinlich das Beste, was Sie tun können, ist, einen Benchmark zu

OK, ich werde das tun, wenn ich mit Allegro weit genug komme, um den Aufwand für den Aufruf von Rust Rust mit dem Aufrufen von C zu vergleichen. Ich lasse dieses Problem vorerst in Ruhe und eröffne ein neues, sobald ich es habe der Benchmark.

Könnten wir eine der Kopien der Argumente vermeiden, indem wir die C-Funktion direkt in den Rust-Stack schreiben lassen, wie es derzeit Rust->C-Aufrufe tun?

Ich hoffe, dass die endgültige Kopie der Argumente aus der Shim-Struktur und in die Argumente der Rostfunktion durch Inlining eliminiert wird. Ich bin mir aber nicht sicher, ob du das meinst.

Ich glaube, dass unsere C-Aufrufe derzeit die Argumente in eine Struktur auf dem Rust-Stack kopieren und dann diese Struktur in den C-Stack kopieren.

@pcwalton Rust->C schreibt derzeit nicht direkt in den C-Stack, da dies spezifisch für i386 ist. Ich wollte vermeiden, Code schreiben zu müssen, der für eine bestimmte Aufrufkonvention spezifisch ist, selbst um den Preis einer gewissen Leistung, um 64-Bit zum Laufen zu bringen. (Ich denke jedoch, dass solche Optimierungen jetzt sinnvoll sein könnten---insbesondere da #1402 darauf hinweist, dass LLVM die Aufrufkonventionen _jedenfalls_ nicht wirklich vollständig handhabt)

Nach dem Lesen der Stack-Switching-Funktion wird die arg-Struktur überhaupt nicht über die Stacks kopiert, der Zeiger auf den vorherigen Stack wird nur an die Funktion übergeben, die auf dem neuen Stack ausgeführt wird, was durchaus Sinn macht.

Die arg-Struktur wird nicht kopiert, aber die Shim-Funktion lädt Werte daraus und schiebt sie erneut auf den neuen Stack. Der alte Code, der verwendet wurde, um die Argumentwerte buchstäblich direkt in den Zielstapel zu schreiben. Dies war auf i386 sinnvoll, aber auf x86_64 ist es viel komplexer herauszufinden, welche Werte auf den Stack usw.

Nach einigen Tests habe ich festgestellt, dass es für Crust-Funktionen sehr schwierig sein wird, sicherzustellen, dass sie nicht versagen. Was derzeit passiert, ist, dass, wenn eine Aufgabe der obersten Ebene (wie main) fehlschlägt, jede Aufgabe fehlschlagen soll. Sobald der Rückruf also versucht, eine Nachricht zu senden (oder wenn er vom Senden einer Nachricht zurückkehrt), kann er fehlschlagen und Veranlassen, dass die Laufzeit abnormal abgebrochen wird.

Ich denke, wir können rust_task so ändern, dass Kill-Anfragen ignoriert werden, sobald Aufgaben wieder in den Rost-Stack aufgenommen wurden. Für Aufgaben, die Ereignisschleifen implementieren, können sie einen Blick auf einen Monitor-Port werfen, nach einer Meldung suchen, die darauf hinweist, dass die Laufzeit fehlschlägt, und herausfinden, wie sie ordnungsgemäß beendet werden kann.

Wenn also eine Aufgabe der obersten Ebene fehlschlägt, gibt sie Fehler an ihre untergeordneten Elemente weiter? Ich glaube, ich verstehe unser Fehlerausbreitungsmodell nicht, ich dachte, es ging von Anfang an aufwärts. Es scheint, als ob Code, der auf C-Stacks läuft, in einer unüberwachten Aufgabe oder ähnlichem ausgeführt werden sollte.

Es verhält sich im Grunde so, als ob 'main' vom Kernel überwacht wird. Wenn also main fehlschlägt, schlägt alles fehl.

Ich nenne das erledigt. Es gibt eine kleine Bereinigung, und ich habe separate Fehler für verbleibende Probleme eingereicht.

Bitte verzeihen Sie diese Auferstehung, aber dieses Problem ist von einem Y-Kombinator-Stück und einigen anderen Seiten verlinkt, und ich hatte kürzlich einen Neuling, der danach gefragt hat, also stelle ich fest, dass ich gemäß dieser Ausgabe und späteren Änderungen Rust von C aus anrufe ist einfach :

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