( asch | 2024. 07. 21., v – 13:22 )

Pontosan azért hoztam mikrovezérlős példát, mert ebben nincsen fekete doboz, aminek a működését nem ismerjük, illetve nem tudjuk befolyásolni. A példában két streamet kezelünk párhuzamosan aszinkron IO API-t használva úgy, hogy egyetlen szálat futtatunk a CPU-n. A JS-szerű pszeudókódban van a closure. A C-szerű pszeudókód pedig mutatja, hogy ezt hogyan hajtanánk végre egyetlen szálon. Persze az objektumok dinamikusan lennének létrehozva, ha ez egy valódi JS interpreter lenne, de a végrehajtás ütemezése pontosan ugyanez lenne.

Direkt írtam, hogy a waitForDataAvailable használata opcionális emiatt még azzal sem lehet kötözködni, hogy az interrupt az egy külön szál. Mert nem kell interrupt sem. Egyetlen szál van, ami sorban feldolgoz mindent. Ez a JS szemantikája is, nincsen több szál a specifikációban, és ha úgy akarjuk, akkor az implementációban sem. És még a kernelt is meg lehetne úgy csinálni, hogy ugyanazon a szálon fusson amin az alkalmazás is fut - ahogy mikrovezérlőn meg lehet csinálni, ugyanúgy PC-n is meg lehetne, csak 0-ról újra kellene írni mindent hozzá. Neked nem lenne gond, mert mindenhez értesz. Én nem szándékozok OS-t írni a közeljövőben.

Ha belegondolsz mivel a JS specifikációja az, hogy _sorban_ hajtja végre az eseménykezelőket, ezért a bufferelésen kívül nincsen szükség párhuzamos működésre egy JS interpreterben. A bufferelést pedig a modern mikrovezérlők automatikusan megcsinálják (körkörös DMA) anélkül, hogy a programnak aktívan csinálnia kellene bármit. Ezért lehet a JS szemantikát megvalósítani mikrovezérlőn egyetlen szálon IRQ nélkül.

>kozmodomor

Érdekesen hangzik, de nem találtam hozzá specifikációt a neten.