Nachdem ich meinen Chatbot auch mal im Chat testen wollte, und eines der Module aufgrund einer Race-Condition nicht funktioniert, und die dort Anwesenden auch nicht so recht weiter wußten (es waren zu dem Zeitpunkt ausschließlich Gnome-Entwickler dort, hehe), da dachte ich mir, muß ich das Ding mal hier posten. Ich denke mal, da es solche Sachen unter Linux/Unix öfter mal zu machen gibt, sollte da ein Standard-Weg sein. Immerhin hat ein "grubby rmmod exec" die Sache kurzfristig behoben :-) (Grubby heißt der Bot)
Ich will einen Kindprozess starten, was auf seine stdin schreiben, und was von seiner stdout lesen. Also kein popen(), sondern bidirektional. Dummerweise bekomme ich meistenst -1 gelesene Bytes zurück, nur selten kommt die erwünschte Antwort. Dabei spielt es keine Rolle, ob der Kindprozess lange braucht (z.B. wenn er in einem Wörterbuch unter /usr/share/trans nachschaut) oder nur kurz, weil er sagt daß er eine Sprache nicht unterstützt (Japanisch oder so).
Der Quelltext ist auf: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ggz/utils/guru/modules/exec.c... Funktion simpleexec().
Das Problem ist, sowohl read als auch waitpid müssen non-blocking sein, und ein Timeout muß es auch noch geben. Und das geht doch sicher irgendwie besser.
Josef Spillner
P.S. Wen es interessiert: Dort wurde das Geheimnis über die neue Elysium-Distribution gelüftet. Siehe http://dobey.free.fr/elysium. Leider ließ sich der Entwickler nicht überreden, KDE einzubauen.
P.P.S. Sebastian, die i18n-Dokumentation mache ich jetzt am Wochenende, da hat sich nämlich noch einiges geändert mit der dynamischen Sprachauswahl.
Hallo Josef,
Am Samstag, dem 18. August 2001 um 01:38:37, schrieb Josef Spillner:
Ich will einen Kindprozess starten, was auf seine stdin schreiben, und was von seiner stdout lesen. Also kein popen(), sondern bidirektional.
Der Quelltext ist auf: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ggz/utils/guru/modules/exec.c... Funktion simpleexec().
Das Problem ist, sowohl read als auch waitpid müssen non-blocking sein, und ein Timeout muß es auch noch geben. Und das geht doch sicher irgendwie besser.
Du wolltest die Eigenschaften zweier pipes benutzen, hast aber die Funktion socketpair verwendet. Sockets sind aber bereits vollduplex - im Gegensatz zu pipes.
$ info libc:
Function: int socketpair (int NAMESPACE, int STYLE, int PROTOCOL, int FILEDES[2]) This function creates a socket pair, returning the file descriptors in `FILEDES[0]' and `FILEDES[1]'. The socket pair is a full-duplex communications channel, so that both reading and writing may be performed at either end.
Alles klar?
Torsten
On Saturday 18 August 2001 09:12, Torsten Werner wrote:
Du wolltest die Eigenschaften zweier pipes benutzen, hast aber die Funktion socketpair verwendet. Sockets sind aber bereits vollduplex - im Gegensatz zu pipes.
Danke für den Tip. Das eigentliche Problem lag aber woanders: Zum einen haben die ausgeführten Programme/Skripte kein flush() gemacht, zum anderen waren sie oft schon beendet als ich vom FD lesen wollte. Wobei Perl gar kein flush() zu kennen scheint, aber mit close(STDOUT) geht's auch. Jedenfalls hänge ich jetzt nach jeder Ausgabe noch ein sleep(1) dran und es scheint zu gehen.
Josef Spillner
On Sun, Aug 19, 2001 at 11:25:01AM +0200, Josef Spillner wrote:
On Saturday 18 August 2001 09:12, Torsten Werner wrote:
Du wolltest die Eigenschaften zweier pipes benutzen, hast aber die Funktion socketpair verwendet. Sockets sind aber bereits vollduplex - im Gegensatz zu pipes.
Danke für den Tip. Das eigentliche Problem lag aber woanders: Zum einen haben die ausgeführten Programme/Skripte kein flush() gemacht, zum anderen waren sie oft schon beendet als ich vom FD lesen wollte. Wobei Perl gar kein flush() zu kennen scheint, aber mit close(STDOUT) geht's auch.
Probiere mal $| = 1; oder so ähnlich
Ciao, Tobias
On Sun, Aug 19, 2001 at 11:25:01AM +0200, Josef Spillner wrote:
beendet als ich vom FD lesen wollte. Wobei Perl gar kein flush() zu kennen scheint, aber mit close(STDOUT) geht's auch.
select FILEHANDLE; $| = 1; # autoflush
Heiko
lug-dd@mailman.schlittermann.de