04. april 2009 - 14:36Der er
7 kommentarer og 1 løsning
Asynkront I/O kald. Hvordan sker dette?
Hej eksperten
Da jeg er ved at se lidt nærmere på asynkront I/O kald, har jeg et spørgsmål som jeg er lidt i tvivl, så jeg håber at der er en her der kan svare. Først lidt baggrundsinformation. Hvis vi antager at jeg starter en process. Denne process opretter en tråd, som laver forskellige opgaver, men den rammer lige pludselig ind i et read, lad os sige fra keyboardet. Dette gør den synkront, altså tråden ryger i en blokeret tilstand og må vente at den får noget data. Dette er selvfølgelig en dårlig måde at gøre det på da tråden ikke kan arbejde videre, så derfor vælger jeg at den skal lave det non-blocking, altså asynkront, men hvordan sker dette? Spawner denne tråd så en ny tråd, som så ryger hen i I/O køen og venter, så tråden som lavede et read, kan køre videre? Denne tråd kan så på en eller anden måde blive gjort opmærksom på at den spawnede tråd har returneret, og derefter hente det data? Jeg ved ikke om keyboardet er et dårligt eksempel.
Håber at høre fra en eller anden, for det har naget mig her de sidste 24 timer.
Ok. Den spawner ikke en ny tråd, men den overlader det så til kernen at tjekke og give tilbage kald? Jeg ved godt at jeg snakker meget generelt. Vil også gerne bare gerne have retningslinierne.
Når IO faktisk sker, så vil kernen/device-driver/whatever læse input og anbring det i en buffer. Det non-blocking kald checker så bare om der er noget i den buffer.
Okay. På den måde. Hvis der ikke er noget i bufferen så kører den videre. Det kan jeg godt se. Ved blocking så venter den altså på at bufferen bliver fyldt. Denne buffer ligger så i userspace?
Ved blocking venter den typisk til at der er mindst 1 byte i bufferen.
Jeg vil tro at den original buffer ligger i system space, men data kan godt blive kopieret til userspace i forbindelse med et kald. Typisk vil et kald nemlig bestå af nogle runtime library kald i user mode og så nogle system kald bagved. Og der kan godt ske en kopiering af data system buffer->runtime library buffre->appplikations buffer.
Jeg troede bare at et asynkront kald ventede til at bufferen var fyldt op/over nogle bytes, og derefter gjorde processen opmærksom på at den har noget data. Men da dette er generelt så kan jeg godt se at det er lidt svært at give et specifikt svar. Nuvel. Smid et svar, for jeg har fået nogenlunde klargjort det jeg søgte!!
De fleste blocking API'er kræver kun 1 byte (undtagen dem som kræver en linie - men de bliver jo oversat til en while løkke som læser indtil der er en hel linie).
Hvorfor rammer den ind i et read? det må være fordi den skal bruge inputtet ellers ville den vel ikke stå der?
Hvis det kun er en del opgave kan man jo lave en tråd til den. Hvis det er meningen at der skal laves noget arbejde hele tiden men at man skal kunne interagere med det må man aflæse om der er nogen der vil noget en gang imellem og så nytter det ikke at have en lang løkke der ikke spørger en gang imellem.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
