[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
[an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]![]() |
![]() |
![]() |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
![]() |
![]() |
![]() |
On Mon, 17 May 2004 09:55:19 +0200, Holger Bille wrote: > Expect er overkill til mit formål. Expect er jo bygget til meget kompleks > interaktion med andre programmer. Det behøver jeg slet ikke. Som sagt er > det til et embedded system, så diskplads betyder noget! Vi glemmer Expect. >> Når man fork()er, er begrebet "den oprindelige proces" jo lidt mudret. >> Men du kan bare arrangere det sådan at parent processsen (den med >> samme pid som du startede med) er den der læser dataen fra dit >> eksterne utility, altså at den er sidste led i pipen >> writer|utility|reader. > > I mine øjne er det ikke spor "mudret". Parent = oprindelig. Jeg mener bare at det i praksis ikke altid betyder noget. Men det er heller ikke noget problem, bortset fra i løsning 2 nedenfor. > Det dur jo > ikke da jeg skal læse fra to (stdout + stderr) pipes og dermed er > tilbage ved deadlock problemet. En "select" lignende mekanisme ville nok > være at foretrække, men hvordan man gør det med pipes har jeg endnu > ikke gennemskuet. Du har ikke deadlock problemer her, bare "buffering-udfordringer". Som jeg ser det har du 3 muligheder: 1. Gør stdout og stderr til det samme ved at lave dup2(1, 2) inden du exec'er dit utility, svarende til "utility 2>&1|reader" i en shell. Ulempen er at du mister muligheden for at skelne mellem stderr og stdout. 2. Fork to forskellige processer, så du har én til hver af stderr og stdout. Ulempen er at hvis der er sammenhæng mellem din behandling af stderr og stdout, får du bare endnu flere problemer. 3. Brug select() og lav din egen buffering hvis det er nødvendigt, fx hvis du har brug for hele linjer af gangen. Hvis du før har brugt select() til sockets, er pipes præcis det samme -- alt er jo en fil (i dette tilfælde en file descriptor) i UNIX. Man kan også sætte O_NONBLOCK flaget på en pipe med fcntl. Ulempen er at det er sværere at kode.
![]() |
![]() |
![]() |
||||||||||||
|
||||||||||||||
![]() | ||||||||||||||
|
||||||||||||||
![]() |
![]() |
![]() |