[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]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [PROGRAMMERING] C rutine til exec + pipe til og fra



> Husk at når du sætter O_NONBLOCK på den ene ende af pipen, kommer det
> også til at gælde for den anden ende
Jeg mener at O_NONBLOCK er en egenskab af en fildeskriptor. Hver process
har sine egne fildeskriptorer. Har du et eksempel på, at det ikke forholder
sig sådan? Kan det være, at du har sat O_NONBLOCK før fork() - så kunne man
måske få den opførsel, du mener at have oplevet.

> Jeg forstår ikke hvorfor du skriver
>   while(close(fd));
> Hvad er det for en fejlbetingelse der kan løses ved at busy-wait'e indtil
> det lykkes, og hvorfor er det vigtigere at lukke filen korrekt i alle
> tilfælde end at undgå uendelige loops i alle tilfælde?
Modtagne signaler kan få close() til at fejle, og her vil retry løse
problemet. I andre fejlsituationer har jeg bare valgt at gøre det samme,
hvilket kan være ok for nogle programmer og skidt for andre. Er det en high
availability daemon, så skal man nok lave mere sofistikeret fejlbehandling.
Dør processen snart efter, rydder kernen op, og man behøver ikke at lukke
fildeskriptorer under alle omstændigheder. Husk, at ulukkede fildeskriptorer
er fejl i samme klasse som memory leaks.

> Jeg synes også det er mere oplagt at bruge
>   execl("/bin/sh", "sh", "-c", command);
>   exit(-1); /* udføres kun hvis /bin/sh ikke kan køres */
> end
>   exit(system(command));
> system() funktionen laver en fork,exec,wait bag din ryg, hvilket jo i
> dette tilfælde er overflødigt.
God pointe.

> Og det er selvfølgelig "bare" proof-of-concept kode, men statisk
> allokerede buffere til at holde outputtet af en kommando der kan generere
> tonsvis af data er nok ikke vejen frem på en platform med begrænset RAM.
1) Jeg ahner ikke hvor meget RAM der er til rådighed på maskiner, der
   kører koden.
2) Jeg ved ikke om de kommandoer man ønsker at køre generer tonsvis af data.
3) Hvad nu HVIS vores memory læsning ikke er pålideligt? :-\
4) Hvad nu HVIS en stor meteorit rammer jorden i nær fremtid? :-(

Naturligvis skal programmet tilpasses de givne omstændigheder. :-)

Hilsen,
Hans-Christian Stadler



 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 22:43 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *