1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache: Rust…

Keine runtime für async/await?

  1. Thema

Neues Thema Ansicht wechseln


  1. Keine runtime für async/await?

    Autor: ibsi 08.11.19 - 10:49

    Der Artikel ist etwas älter:
    https://dev.to/gruberb/explained-how-does-async-work-in-rust-46f8

    Aber dort steht:
    > The Rust Language Team decided not to include any runtime. Rust wants to be as small as possible, and to be able to swap parts in and out as needed. Therefore you need to rely on crates to provide the appropiate runtime for you.


    Sehe ich das richtig das man sich also eine runtime selber bauen muss oder das man crates wie tokio nutzen muss?

    In der aktuellen Version funktioniert zwar:

    async fn async_func (){
    ...
    }

    aber

    fn calling_func() {
    let future = async_func();
    let result = future.await;

    dbg!(result);
    }

    Funktioniert natürlich nicht (Await nur in async). Aber ein block_on oder ähnliches scheint es in der Standardbibliothek nicht zu geben. Also -> selbst schreiben oder crate verwenden.

    Sehe ich das richtig oder habe ich da was übersehen?

    Ich suche aktuell eine einfache Möglichkeit eine Liste von Dateien asynchron abzuarbeiten. Quasi:

    // javascript Beispiel
    const list = ['1', '2', '3', '4'];
    const promiseList = [];

    doForAll(list)
    .then((data) => {
    console.log(data);
    });

    async function doForAll(allItems) {
    return await Promise.all(allItems.map((stringNumber) => {
    return toInteger(stringNumber);
    }));
    }

    function toInteger(stringNumber) {
    return new Promise((resolve, reject) => {
    resolve(parseInt(stringNumber));
    });
    }


    So was in der Art will ich in Rust machen ... aber wie?

  2. Re: Keine runtime für async/await?

    Autor: azeu 08.11.19 - 10:59

    Darf man fragen warum Du das überhaupt asynchron machen willst?

    Bei JS ist es ein notwendiges Übel weil die Dateien auf dem Server liegen und der Client halt warten muss. Rust läuft aber auf dem Server. Wozu brauchst Du da eine asynchrone Verarbeitung genau?

    DU bist ...

  3. Re: Keine runtime für async/await?

    Autor: ibsi 08.11.19 - 11:03

    azeu schrieb:
    --------------------------------------------------------------------------------
    > Darf man fragen warum Du das überhaupt asynchron machen willst?
    weil das was ich da ausführe länger dauert.

    >
    > Bei JS ist es ein notwendiges Übel weil die Dateien auf dem Server liegen
    > und der Client halt warten muss. Rust läuft aber auf dem Server. Wozu
    > brauchst Du da eine asynchrone Verarbeitung genau?
    Das JS war nur als Beispiel gedacht.
    Weil auch auf einem Server möchte man eine schnelle Verarbeitung haben. Wenn ich 1000 Dateien habe und alle aufmache und damit was mache, dann dauert das. Und das kann er auch parallel machen.

    Es ist aber nicht einmal eine Serveranwendung, sondern eine Clientanwendung.

  4. Re: Keine runtime für async/await?

    Autor: azeu 08.11.19 - 11:15

    Hmm, wobei ich mir nicht sicher bin ob das unterm Strich schneller geht.

    Der Flaschenhals Festplatte wird da wohl etwas im Weg sein.

    DU bist ...

  5. Re: Keine runtime für async/await?

    Autor: ibsi 08.11.19 - 11:38

    Tja, kommt auf einen Versuch drauf an :D

  6. Re: Keine runtime für async/await?

    Autor: Graveangel 08.11.19 - 11:49

    ibsi schrieb:
    --------------------------------------------------------------------------------
    > In der aktuellen Version funktioniert zwar:
    >
    > async fn async_func (){
    > ...
    > }
    >
    > aber
    >
    > fn calling_func() {
    > let future = async_func();
    > let result = future.await;
    >
    > dbg!(result);
    > }
    >
    > Funktioniert natürlich nicht (Await nur in async). Aber ein block_on oder
    > ähnliches scheint es in der Standardbibliothek nicht zu geben. Also ->
    > selbst schreiben oder crate verwenden.
    >
    > Sehe ich das richtig oder habe ich da was übersehen?

    Du hast etwas übersehen.
    Dein Main ist vermutlich nicht asynchron, wenn du aber eine async ohne await aufrufst und darin await nutzt, sollte es gehen.

    Vermutlich wirst du aber die main blockieren müssen.

  7. Re: Keine runtime für async/await?

    Autor: ibsi 08.11.19 - 11:55

    Graveangel schrieb:
    --------------------------------------------------------------------------------
    > ibsi schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > In der aktuellen Version funktioniert zwar:
    > >
    > > async fn async_func (){
    > > ...
    > > }
    > >
    > > aber
    > >
    > > fn calling_func() {
    > > let future = async_func();
    > > let result = future.await;
    > >
    > > dbg!(result);
    > > }
    > >
    > > Funktioniert natürlich nicht (Await nur in async). Aber ein block_on
    > oder
    > > ähnliches scheint es in der Standardbibliothek nicht zu geben. Also ->
    > > selbst schreiben oder crate verwenden.
    > >
    > > Sehe ich das richtig oder habe ich da was übersehen?
    >
    > Du hast etwas übersehen.
    > Dein Main ist vermutlich nicht asynchron,
    Korrekt, diese soll synchron arbeiten.


    > wenn du aber eine async ohne
    > await aufrufst und darin await nutzt, sollte es gehen.
    >
    Aber wenn ich eine async fn habe, dann muss ich doch "future".await aufrufen, damit das überhaupt startet. Await geht aber ja nur in async functions. Da hatte ich gesehen das es in tokio z.B. ein block_on gibt. Dies ruft man in der nicht-asynchronen funktion auf und startet die asynchrone verarbeitung.

    > Vermutlich wirst du aber die main blockieren müssen.
    Das wäre nicht das Problem

  8. Re: Keine runtime für async/await?

    Autor: caelis 08.11.19 - 22:18

    Dein Problem sieht eher nach einem CPU bound problem aus (soweit ich das anhand von deinem beispiel erahnen kann), für so was nimmst du besser rayon.

    ... wenns i/o bound ist (z. b. wegen dem einlesen der dateien), dann ja, dann brauchst du ne runtime, tokio oder (wohl für file io besser) async_std

  9. Re: Keine runtime für async/await?

    Autor: ibsi 09.11.19 - 10:22

    Dateien umbenennen, ist das schon i/o in diesem Kontext?

  10. Re: Keine runtime für async/await?

    Autor: caelis 09.11.19 - 16:49

    Dateien umbenennen -> Ja, das wäre dann I/O. async-std/0.99.12/async_std/fs/fn.rename.html

    pub async fn rename<P: AsRef<Path>, Q: AsRef<Path>>(
    from: P,
    to: Q
    ) -> Result<()>

    ...aber ich denke async wird dir hier (je nachdem wie dein Programm aufgebaut ist) nicht viel (performance) bringen. Async ist dafür da, tausende von kleinen Requests auf wenige Threads zu verteilen (anzahl threads = anzahl CPU kerne). Typischerweise genau diese Situation hat man bei einem Webserver. ... oder für Situationen wenn Blockieren nicht möglich ist (JavaScript). ... Für alles andere kannst du auch Threads verwenden / Rayon.

  11. Re: Keine runtime für async/await?

    Autor: ibsi 09.11.19 - 19:41

    Danke. Geht tatsächlich nicht darum die letzte Millisekunde herauszukitzeln. Wenn es 1 Prozent ist, wäre es ausreichend. Ist hauptsächlich zum lernen von rust.

    Nochmal vielen Dank für die ausführliche Antwort. Denke ich werde es dann mal mit rayon versuchen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. ESG Elektroniksystem- und Logistik-GmbH, Donauwörth
  2. USP SUNDERMANN CONSULTING Unternehmens- und Personalberatung, Fürth
  3. BG-Phoenics GmbH, Hannover
  4. FINARX GmbH, Darmstadt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,99€
  2. 65,99€
  3. 3,61€
  4. 53,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Power-to-X: Sprit aus Ökostrom, Luft und Wasser
Power-to-X
Sprit aus Ökostrom, Luft und Wasser

Die Energiewende ist ohne synthetische Treibstoffe nicht zu schaffen. In Karlsruhe ist eine Anlage in Betrieb gegangen, die das mithilfe von teilweise völlig neuen Techniken schafft.
Ein Bericht von Wolfgang Kempkens

  1. The Ocean Cleanup Interceptor fischt Plastikmüll aus Flüssen
  2. The Ocean Cleanup Überarbeiteter Müllfänger sammelt Plastikteile im Pazifik

Fritzbox mit Docsis 3.1 in der Praxis: Hurra, wir haben Gigabit!
Fritzbox mit Docsis 3.1 in der Praxis
Hurra, wir haben Gigabit!

Die Fritzbox 6591 Cable für den Einsatz in Gigabit-Kabelnetzen ist seit Mai im Handel erhältlich. Wir haben getestet, wie schnell Vodafone mit Docsis 3.1 tatsächlich Daten überträgt und ob sich der Umstieg auf einen schnellen Router lohnt.
Ein Praxistest von Friedhelm Greis

  1. Nodesplits Vodafone bietet 500 MBit/s für 20 Millionen Haushalte
  2. Sercomm Kabelmodem für bis zu 2,5 GBit/s vorgestellt
  3. Kabelnetz Die Marke Unitymedia wird verschwinden

Red Dead Redemption 2 für PC angespielt: Schusswechsel mit Startschwierigkeiten
Red Dead Redemption 2 für PC angespielt
Schusswechsel mit Startschwierigkeiten

Die PC-Version von Red Dead Redemption 2 bietet schönere Grafik als die Konsolenfassung - aber nach der Installation dauert es ganz schön lange bis zum ersten Feuergefecht in den Weiten des Wilden Westens.

  1. Rockstar Games Red Dead Redemption 2 belegt 150 GByte auf PC-Festplatte
  2. Rockstar Games Red Dead Redemption 2 erscheint für Windows-PC und Stadia
  3. Rockstar Games Red Dead Online wird zum Rollenspiel

  1. Datenschmuggel: US-Gericht schränkt Durchsuchungen elektronischer Geräte ein
    Datenschmuggel
    US-Gericht schränkt Durchsuchungen elektronischer Geräte ein

    US-Grenzbeamte dürfen nicht mehr so einfach die Smartphones und Laptops von Einreisenden untersuchen. Es muss ein begründeter Verdacht auf Datenschmuggel vorliegen.

  2. 19H2-Update: Microsoft veröffentlicht Windows 10 v1909
    19H2-Update
    Microsoft veröffentlicht Windows 10 v1909

    Das November-Update ist da: Bei Microsoft steht Windows 10 v1909 zum Download bereit. Laut Hersteller handelt es sich um ein Feature Update, die Installation geht schnell und die Neuerungen sind überschaubar.

  3. Sparvorwahlen: Tele2 feiert Rettung von Call-by-Call
    Sparvorwahlen
    Tele2 feiert Rettung von Call-by-Call

    Verbände und die Deutsche Telekom haben sich auf die freiwillige Weiterführung von Call-by-Call und Pre-Selection verständigt. Es gibt immer noch Nutzer dieser Sparvorwahlen.


  1. 17:23

  2. 17:00

  3. 16:45

  4. 16:30

  5. 16:12

  6. 15:30

  7. 15:15

  8. 15:00