A connect nem fog blokkolni, ha előtte a socket-et SOCK_NONBLOCK opcióval hozod létre.De fog, mert az csak a read/write-ra vonatkozik, amiket többször is hívhatsz. De tegyük fel a vicc kedvéért, hogy így van, hogy értesül akkor a js motor róla, hogy végzett a connect rendszerhívás? Másold ide kérlek a man page-ből azt a részt, ami a callback indító mechanizmushoz szolgál.
Tipikusan addig a kernel tárolja a beérkezett adatcsomagot.Nyilván, a kérdés nem ez volt, hanem az, hogy mit csinál a szál közben, ha állítólag még kernel szinten sincs blokkolt szál?
Amikor a user módú program oda jut, akkor kéri a kernelt,"Oda jut"? Hogyan? Mikor és hogy jut oda, ha az egy szem szálán épp a fő Javascript szál futtatásával van elfoglalva és nem is kéri a kernel-t? (Állításod szerint a kernel kérése már megtörtént és egyből vissza is tért). Másold ide kérlek a man page-ből azt a részt, ami a callback indító mechanizmushoz szolgál.
A callback-et úgy képzeld el, mint egy adatstruktúra (kb. mint egy function pointer és még egyéb adatok).Na és mi a "function pointer", ha nem egy utasításszámláló érték? Az a bajod, hogy sejtelmed sincs az alapfogalmakról és még azt is összekevered, mi a multithreading és a multitasking.
Ha blokkoló connect-et használtál, akkor sleep-be teszi a user módú szálat.Na de a) azt mondtad nincs blokkolás, b) nem történt alarm rendszerhívás se. (A sleep LIBC FUNKCIÓ által kiadott ALARM rendszerhívás hatására bekövetkező timer-based blocking és az IO blocking két hullára különböző dolog, de még ezt is sikerült totál összekeverted, gratulálok!).
Ha nem blokkoló connect-et használtál, akkor ugye fut tovább a user módú szál a további utasításaival.Na de akkor hogy és miként értesül az IO művelet befejeztéről? A connect-et nem hívogathatod többször, mint a read-et/write-ot. Másold ide kérlek a man page-ből azt a részt, ami a callback indító mechanizmushoz szolgál.
Ezt nem kell külön "tudni". Egy szál van, és az vagy JavaScript utasításokat hajt végre, tehát magát a callback-et.Lassan a testtel, hapsikám! Az az egyetlen JavaScript szál épp a főszálat hajta végre! Honnan is tudja egész pontosan, hogy most már a callbecket kellene futtatnia helyette?
Hogy félrevezető, mert a JavaScript programozási modelljében egyetlen szál van.Már az AI is megmondta neked, hogy hülye vagy, több szál van. Még mindig nem vagy képes felfogni, hogy csak azért, mert a sok-sok szál nincs kivezetve a JavaScript API-ra, és az csak egyet lát, attól még a motorháztető alatt bizony mind-mind ott vannak a szálak.
Ha már nincs mit számolni CPU-n, mert a főprogram összes JavaScript-jét végrehajtotta, akkor igen, várni fog, hogy valami IO befejeződjön, amit a főprogram korábban elindított.Na de azt mondtad, nincs blokkolódás....
Ezt nevezheted blokkolásnak, de azért félrevezető, mert a blokkolást akkor szokták használni, ha amúgy mást is tudnál csinálni.Citation required! És ellentmond a fenti mondatodnak. Gyengébbek kedvéért a helyes definíció: A blokkolás azt jelenti, hogy ez a szál nem futhat, mert kénytelen várakozni erőforrásra, és ennek az égadta világon semmi köze sincs ahhoz, hogy van-e esetleg még más szál és hogy azok épp milyen státuszúak (illetve még az sem számít, hogy milyen erőforrásra is várakozik épp, lehet az IO művelet, CPU, időzítő stb.). A blokkolt szál fogalmában NEM szerepel többi szál.
És ez akkor "blokkol" valamit, ha a következő callback bekövetkezne. Ez ugye akkor van, ha a főprogram vagy valamelyik callback még továbbra is JavaScript utasításokat hajt végre.Na de akkor ez nem aszinkron.
Ha közben a főszál foglalt valamivel, akkor a timeout késni fog.Nem ezt mondtad, hanem hogy egyáltalán nem fog futni, amíg a főprogram és a beütemezett callbackek teljesen be nem fejeződtek. Ez kurvára nem ugyanaz.
És nyugodtan futtasd le magad is.Kipróbáltam Firefox, Chromium és még Netsurf (+libjavascript) böngészőkkel is, nincs késés (a megadott hibahatáron túl), a setTimeout szál párhuzamosan fut a fő szállal.