Wobei mir noch nicht so ganz in den Kopf will, warum Du den Webserver mit zusätzlicher Arbeit belasten willst, während ein ohnehin langsames Programm läuft. Wenn Du dem Benutzer Aktivität vorgaukeln willst, benutze ein animiertes GIF, das Du nach Ende der langen Arbeit ausblendest oder ersetzt. Oder verarbeite die Ausgabe des Kindprozesses direkt im CGI, noch während der Kindprozess die Ausgabe anliefert. Das dürfte in aller Regel die effizienteste Lösung sein.
Ich hatte das Programm ursprünglich ohne Fork im Einsatz.
Das Problem dabei ist, dass die Ausgabe des externen Programms schlagartig am Ende erfolgt, und nicht Stück für Stück.
In der neuen Version ist die Startzeit des Programms aber so übermäßig angewachsen, dass es zwischen Browser und Server zu einem Timeout kommt, bevor das externe Programm sein Ergebnis zurückliefern kann.
(Wobei das Problem früher schon auftreten konnte, wenn eine besonders große Datei übergeben wurde, aber da das selten bis gar nicht vorkam, war es da nicht störend.)
Deswegen wollte ich die Verbindung am Leben erhalten, indem ich ihm vom einen Prozeßteil aus so lange die "Bitte Warten"-Nachricht schicke, bis er im anderen Prozeßteil zu einem Ergebnis gekommen ist.
Also für mich klingt das nach verlorener Liebesmühe. Ich kenn mich mit fork nicht aus, aber wir reden über ein CGI Skript, das über vom Server gestartet und u.U. auch vorzeitig beendet wird. Du versuchst hiermit ja dieses Limit zu verlängern, ich kenn mich mit diesen Systemnahen Oprationen nicht aus, fände es aber merkwürdig wenn dies so gehen würde. Ich denke mal das fork im zusammenhang mit CGI Skripten soweiso selten eine sinnvolle Sache ist.
Struppi.