[C] pipe() blijft hangen

left part of the evil twins

Je hebt vanzelfsprekend zelf al gestept door de code en/of middels tactisch geplaatste printf's gecontroleerd op welke statement hij hangt?

Oftewel: heb je al gedebugged of moeten wij dat voor je doen?

offtopic:
en ik heb trouwens al een schijthekel aan openingsaccolades achteraan de regel plaatsen, maar als je vervolgens ook nog zo inconsequent als wat bent met je indentering wordt het geheel helemaal onbegrijpelijk

[ Voor 35% gewijzigd door curry684 op 02-03-2004 16:56 ]

dinsdag 2 maart 2004 17:06

Acties:

dinsdag 2 maart 2004 17:07

De reindented versie (voor andere mensen die allergisch zijn voor slecht geindenteerde code):

C:

pid1 = fork();
if (pid1 == -1) {
    return -1;
}
if (pid1 == 0) { // CHILD
    pid2 = fork();
    if (pid2 == -1) {
        return -1;
    }
    if (pid2 == 0) {   // CHILD
        if ((close(1)) < 0) {
            return -1;
        }
        if ((dup(fd[1])) < 0) {
            return -1;
        }
        if ((close(fd[0])) < 0) {
            return -1;
        }
        if((execvp(params1[0], params1)) == -1) {
            fprintf(stdout,"%s: Unknown command\n", params1[0]);
            break;
        }
        exit(0);
    }
    else {   // PARENT
        if ((close(0)) < 0) {
            return -1;
        }
        if ((dup(fd[0])) < 0) {
            return -1;
        }
        if ((close(fd[1])) < 0) {
            return -1;
        }
        if((execvp(params2[0], params2)) == -1) {
            fprintf(stdout,"%s: Unknown command\n", params1[0]);
            break;
        }
        wait(0);
    }
    exit(0);
}
else {  // PARENT
    wait(0);
}

Acties:

Verwijderd

Topicstarter

curry684 schreef op 02 maart 2004 @ 16:55:
Je hebt vanzelfsprekend zelf al gestept door de code en/of middels tactisch geplaatste printf's gecontroleerd op welke statement hij hangt?

Oftewel: heb je al gedebugged of moeten wij dat voor je doen?

dit wordt uitgevoerd

C:

if ((execvp(params1[0], params1)) == -1) 
{  
        fprintf(stdout,"%s: Unknown command\n", params1[0]);
        break;
}

maar dit

C:

if ((execvp(params2[0], params2)) == -1)
 {  
        fprintf(stdout,"%s: Unknown command\n", params1[0]);
        break;
}

blijft hangen omdat dit child proces (althans dat is wat ik denk) blijft wachten op input, hij heeft de output van "ls" al gelezen, maar kan niet bepalen of er nog meer komt, dus blijft hij wachten, terwijl het andere proces al exit(0) heeft uitgevoerd.

dinsdag 2 maart 2004 17:15

Acties:

left part of the evil twins

Heb je de documentatie van execvp al wel eens gelezen?

dinsdag 2 maart 2004 17:18

Acties:

Verwijderd

Topicstarter

curry684 schreef op 02 maart 2004 @ 17:15:[/b]
Heb je de documentatie van execvp al wel eens gelezen?

ja

bedoel je dat de exit(0) na de execvp nooit uitgevoerd wordt?
dat maakt toch geen verschil? ofwel?

[ Voor 8% gewijzigd door Verwijderd op 02-03-2004 17:19 ]

dinsdag 2 maart 2004 17:20

Acties:

left part of the evil twins

Verwijderd schreef op 02 maart 2004 @ 17:18:
[...]
ja

bedoel je dat de exit(0) na de execvp nooit uitgevoerd wordt?
dat maakt toch geen verschil? ofwel?

Ik vraag me af of je wel het goede programma zit te debuggen

dinsdag 2 maart 2004 17:24

Acties:

Verwijderd

Topicstarter

curry684 schreef op 02 maart 2004 @ 17:20:
[...]

Ik vraag me af of je wel het goede programma zit te debuggen

hoe bedoel je?
ik vat je niet echt....sorry

dinsdag 2 maart 2004 17:29

Acties:

left part of the evil twins

Verwijderd schreef op 02 maart 2004 @ 17:24:
[...]
hoe bedoel je?
ik vat je niet echt....sorry

Nevermind ik zat scheef te kijken

Ik moet me als Windowshippie niet bemoeien met Linux-code

dinsdag 2 maart 2004 17:34

Acties:

dinsdag 2 maart 2004 17:37

Hoe kan een exec call nu blijven hangen? Ofwel hij faalt (en dan krijg je een foutmelding terug) ofwel je huidige proces wordt overschreven en dan krijg je dus geen return value meer terug.

Waar is trouwens die eerste fork voor bedoeld? Want in het parent process doe je niets dan wachten op het child process; het lijkt mij dat je dan net zo goed de hele fork operatie achterwege kan laten.

Acties:

left part of the evil twins

Soultaker schreef op 02 maart 2004 @ 17:34:
Hoe kan een exec call nu blijven hangen? Ofwel hij faalt (en dan krijg je een foutmelding terug) ofwel je huidige proces wordt overschreven en dan krijg je dus geen return value meer terug.

Dat bedoelde ik ook met 'je zit in het verkeerde proces' maar zag toen pas dat de testcase 2 native Linux-operaties zijn (is wc toch ook?). Ergo de exec zelf kan niet hangen, dus moet het hier ergens in de code zitten... denk ik

dinsdag 2 maart 2004 17:39

Acties:

Verwijderd

Topicstarter

Soultaker schreef op 02 maart 2004 @ 17:34:
Hoe kan een exec call nu blijven hangen? Ofwel hij faalt (en dan krijg je een foutmelding terug) ofwel je huidige proces wordt overschreven en dan krijg je dus geen return value meer terug.

Waar is trouwens die eerste fork voor bedoeld? Want in het parent process doe je niets dan wachten op het child process; het lijkt mij dat je dan net zo goed de hele fork operatie achterwege kan laten.

Hij blijft denk ik hangen in de zin van dat hij niet weet of hij nog meer input krijgt (output van "ls"), dus blijft hij wachten, hij moet volgens mij iets van EOF lezen ofzo, of de pipe moet geclosed worden. Ik heb al geprobeerd om de pipe te closen, maar ook dat werkt helaas niet.

De parent van de eerste fork() is de shell zelf, die loopt weer terug om het volgende commando te lezen en te executen

dinsdag 2 maart 2004 17:43

Acties:

dinsdag 2 maart 2004 18:03

Ik zal het probleem dan wel weer niet snappen. Dit is trouwens ook het eerste topic met pipe() in de titel waar geen pipe() in voorkomt.

Ok, het gaat dus om het correct verbinden van streams? Of gaat het erom dat de shell blijft hangen?

Wat was precies de bedoeling met die streams? Wat je nu namelijk doet, is stdout afsluiten, stdin op de file descriptor van stdout zetten, en vervolgens de originele stdin ook sluiten. Je nieuwe proces heeft dan dus een gesloten file descriptor 0 en een open file descriptor 1 waar 'ie z'n invoer uit moet gaan lezen. Die configuratie slaat natuurlijk nergens op; dat kan nooit de bedoeling zijn.

Verder heb je om een stream via een pipe om te leiden natuurlijk wel ergens een pipe call nodig. Ik zie 'm nu niet.

[ Voor 111% gewijzigd door Soultaker op 02-03-2004 17:50 ]

Acties:

Verwijderd

Topicstarter

Soultaker schreef op 02 maart 2004 @ 17:43:

Ok, het gaat dus om het correct verbinden van streams? Of gaat het erom dat de shell blijft hangen?

Wat was precies de bedoeling met die streams? Wat je nu namelijk doet, is stdout afsluiten, stdin op de file descriptor van stdout zetten, en vervolgens de originele stdin ook sluiten. Je nieuwe proces heeft dan dus een gesloten file descriptor 0 en een open file descriptor 1 waar 'ie z'n invoer uit moet gaan lezen. Die configuratie slaat natuurlijk nergens op; dat kan nooit de bedoeling zijn.

Verder heb je om een stream via een pipe om te leiden natuurlijk wel ergens een pipe call nodig. Ik zie 'm nu niet.

Het gaat erom dat de shell blijft hangen.

close(1) sluit stdout af, met een dup(fd[1]), krijg ik een filedescriptor terug met 1, dus stdout is de pipe geworden en omdat ik niet hoeft te lezen van de pipe sluit ik fd[1] af. En omgekeerd om ervoor te zorgen dat de pipe stdin wordt, dus close(0), dup(fd[0]) en close(fd[0])

pipe staat er inderdaad niet bij, ik heb namelijk niet de gehele code gepost.
Maar dat is OK, de shell kan namelijk m.u.v. een piped commando al het andere werk netjes executen, alleen bij bijv. "ls | wc" blijft ie hangen en gebeurt er niks meer

bedoeling van de streams is dat het eerste child "ls" uitvoert (zie execvp met params1) en de output ervan naar een pipe schrijft (pipe is stdout voor dit proces), waar het tweede child dat "wc" uitvoert (zie execvp met params2) uit leest (pipe is stdin voor dit proces). Eerste process, oftewel de "ls" wordt prima uitgevoerd en output wordt naar pipe geschreven, maar process wat "wc" uitvoert blijft maar wachten, heb ik het idee.

[ Voor 21% gewijzigd door Verwijderd op 02-03-2004 18:08 ]

dinsdag 2 maart 2004 20:17

Acties: