Onderwerp: Een Perl fork() vraag.

Ik heb ter illustratie van m'n vraag dit:
http://freenews.xs4all.nl/cgi-bin/fork.pl script in elkaar gezet. Je ziet dat
het script tijdens de uitvoering ervan niets meldt totdat het script helemaal
is uitgevoerd.

M'n vraag is: hoe kan ik ervoor zorgen dat in ieder geval de Parent zich
real-time meldt? De Children hoeven zich niet te melden van me, als de Parent
maar de mogelijkheid heeft de status van de Children real-time te melden.

Elk inzicht is welkom. TIA.

--
Posted via usenet4all.org

Hans <private@usenet4all.invalid>:
> Ik heb ter illustratie van m'n vraag dit:
> http://freenews.xs4all.nl/cgi-bin/fork.pl script in elkaar gezet. Je
> ziet dat het script tijdens de uitvoering ervan niets meldt totdat het
> script helemaal is uitgevoerd.
>
> M'n vraag is: hoe kan ik ervoor zorgen dat in ieder geval de Parent
> zich real-time meldt? De Children hoeven zich niet te melden van me,
> als de Parent maar de mogelijkheid heeft de status van de Children real-
> time te melden.

Zet dit eens bovenaan je script:

use IO::Handle;

autoflush STDOUT 1;

Het probleem is dat Perl normaal gesproken output blijft bufferen totdat
een bepaalde buffergrootte bereikt is; pas dan wordt de zaak naar de
uitvoer geschreven (een flush). Met 'autoflush' wordt direct na elke
print/write geflusht.

--
robert

On 05 Aug 2008 08:25 {n.i.w.s}@allyourbass.org.invalid (robert) wrote:

>> Ik heb ter illustratie van m'n vraag dit:
>> http://freenews.xs4all.nl/cgi-bin/fork.pl script in elkaar gezet. Je
>> ziet dat het script tijdens de uitvoering ervan niets meldt totdat het
>> script helemaal is uitgevoerd.

>> M'n vraag is: hoe kan ik ervoor zorgen dat in ieder geval de Parent
>> zich real-time meldt? De Children hoeven zich niet te melden van me,
>> als de Parent maar de mogelijkheid heeft de status van de Children real-
>> time te melden.

> Zet dit eens bovenaan je script:
> use IO::Handle;
> autoflush STDOUT 1;

Ik heb:

select STDOUT; $| = 1;

in m'n script verwerkt, dat is IMO synoniem aan wat jij voorstelt.

> Het probleem is dat Perl normaal gesproken output blijft bufferen totdat
> een bepaalde buffergrootte bereikt is; pas dan wordt de zaak naar de
> uitvoer geschreven (een flush). Met 'autoflush' wordt direct na elke
> print/write geflusht.

Klopt, dat staat uitvoerig in de doc's beschreven. Het rare is, dat als ik het
script in de shell start niet wordt gebufferd (want dit is inderdaad 't
probleem denk ik).

--
Posted via usenet4all.org

Hans <private@usenet4all.invalid>:
> On 05 Aug 2008 08:25 {n.i.w.s}@allyourbass.org.invalid (robert) wrote:
>
>> Zet dit eens bovenaan je script:
>> use IO::Handle;
>> autoflush STDOUT 1;
>
> Ik heb:
>
> select STDOUT; $| = 1;
>
> in m'n script verwerkt, dat is IMO synoniem aan wat jij voorstelt.

Ja, dat klopt. Maar ik bedenk me zojuist dat ik mijn testscript heb getest
met curl, wat zelf niet buffert. Daarin werkt het prima. Als ik mijn
testscript vanuit m'n browser open gaat het helaas toch mis, kennelijk
wordt de uitvoer ook nog eens in de browser gebufferd, tot aan het moment
dat de verbinding afgesloten wordt.

De enige manier die ik kan verzinnen om dát op te lossen is via een
multipartachtig-iets. Als je in de manpage van de CGI module zoekt naar
'Server Push' dan vind je een simpel voorbeeld. Overigens moet je je script
dan wel hernoemen zodat de naam begint met 'nph-' (als je Apache gebruikt).

>> Het probleem is dat Perl normaal gesproken output blijft bufferen totdat
>> een bepaalde buffergrootte bereikt is; pas dan wordt de zaak naar de
>> uitvoer geschreven (een flush). Met 'autoflush' wordt direct na elke
>> print/write geflusht.
>
> Klopt, dat staat uitvoerig in de doc's beschreven. Het rare is, dat als
> ik het script in de shell start niet wordt gebufferd (want dit is
> inderdaad 't probleem denk ik).

Als je een script vanuit de shell start is de uitvoer sowieso meestal
linebuffered i.p.v. blockbuffered.

--
robert

Op Tue, 05 Aug 2008 09:41:32 +0000, schreef robert..

>>> Zet dit eens bovenaan je script:
>>> use IO::Handle;
>>> autoflush STDOUT 1;

>> Ik heb:

>> select STDOUT; $| = 1;

>> in m'n script verwerkt, dat is IMO synoniem aan wat jij voorstelt.

> Ja, dat klopt. Maar ik bedenk me zojuist dat ik mijn testscript heb
> getest met curl, wat zelf niet buffert. Daarin werkt het prima. Als ik
> mijn testscript vanuit m'n browser open gaat het helaas toch mis,
> kennelijk wordt de uitvoer ook nog eens in de browser gebufferd, tot aan
> het moment dat de verbinding afgesloten wordt.

Vreemd. Ik heb een aantal scripts die real-time status laten zien, nooit
last gehad van 'browser-side buffering'. Nooit van gehoord eigenlijk ook.

> De enige manier die ik kan verzinnen om dát op te lossen is via een
> multipartachtig-iets. Als je in de manpage van de CGI module zoekt naar
> 'Server Push' dan vind je een simpel voorbeeld. Overigens moet je je
> script dan wel hernoemen zodat de naam begint met 'nph-' (als je Apache
> gebruikt).

Ik heb zonet het simpelste nph-script in elkaar geflanst wat ik maar kon
bedenken en dat wordt ook gebufferd..

---8<---
#!/usr/bin/perl

$| = 1;
print "$ENV{'SERVER_PROTOCOL'} 200 OK\n";
print "Server: $ENV{'SERVER_SOFTWARE'}\n";
print "Content-type: text/plain\n\n";

for ( $loop = 10; $loop >= 0; $loop-- ) {
print "$loop\n";
sleep (1);
}
print "Done.\n";
exit (0);
---8<---

Ik denk dat ik iets verkeerd heb gedaan met de installatie van m'n
server, anders weet k het ook niet.

>>> Het probleem is dat Perl normaal gesproken output blijft bufferen
>>> totdat een bepaalde buffergrootte bereikt is; pas dan wordt de zaak
>>> naar de uitvoer geschreven (een flush). Met 'autoflush' wordt direct
>>> na elke print/write geflusht.

>> Klopt, dat staat uitvoerig in de doc's beschreven. Het rare is, dat als
>> ik het script in de shell start niet wordt gebufferd (want dit is
>> inderdaad 't probleem denk ik).

> Als je een script vanuit de shell start is de uitvoer sowieso meestal
> linebuffered i.p.v. blockbuffered.

Inderdaad, stom van me. Ik heb zonet Apache 2 geinstalleerd en ga eens
kijken of het iets typisch is van Abyss. Dank je voor 't meedenken in
ieder geval :-)

--
Constant change is here to stay

Ronin <ronin@xs4all.invalid>:
> Ik heb zonet het simpelste nph-script in elkaar geflanst wat ik maar kon
> bedenken en dat wordt ook gebufferd..

Hoe test je dat?

> Ik heb zonet Apache 2 geinstalleerd en ga eens kijken of het iets typisch
> is van Abyss.

Ah, ik ging er van uit dat je Apache gebruikte, daar heb ik mee getest in
ieder geval

--
robert

Op Tue, 05 Aug 2008 21:29:07 +0000, schreef robert..

>> Ik heb zonet het simpelste nph-script in elkaar geflanst wat ik maar
>> kon bedenken en dat wordt ook gebufferd..

> Hoe test je dat?

Dat is een aanname. nph-scripts sturen de data direct naar de client. Als
dat niet gebeurd wordt die data ergens opgehouden. Dat 'ophouden' noem ik
bufferen.

>> Ik heb zonet Apache 2 geinstalleerd en ga eens kijken of het iets
>> typisch is van Abyss.

> Ah, ik ging er van uit dat je Apache gebruikte, daar heb ik mee getest
> in ieder geval

Ik ga nog een beetje lezen en testen :-)

--
Constant change is here to stay

Op Tue, 05 Aug 2008 21:29:07 +0000, schreef robert..

<knipje>

>> Ik heb zonet Apache 2 geinstalleerd en ga eens kijken of het iets
>> typisch is van Abyss.
>
> Ah, ik ging er van uit dat je Apache gebruikte, daar heb ik mee getest
> in ieder geval

Helaas, Apache geeft hetzelfde resultaat. Verder prutsen maar weer :-)

--
Constant change is here to stay

Ronin <ronin@xs4all.invalid>:
> Op Tue, 05 Aug 2008 21:29:07 +0000, schreef robert..
>
>>> Ik heb zonet het simpelste nph-script in elkaar geflanst wat ik maar
>>> kon bedenken en dat wordt ook gebufferd..
>
>> Hoe test je dat?
>
> Dat is een aanname. nph-scripts sturen de data direct naar de client.

Sterker nog, ook *niet* nph-scripts doen dat, in ieder geval in Apache
(sinds 1.3, las ik). Dus daar (ik reageer meteen even op je volgende
posting ligt het niet aan.

Maar de methode van testen is wel belangrijk: de commandline HTTP client
'curl' laat bij onderstaand script de eerste twee regels uitvoer direct
zien (zoals je zou verwachten), maar mijn browser Safari wacht gewoon
totdat de verbinding gesloten wordt en laat dan pas, in 1 keer, alle
uitvoer zien:
-test.pl-
#!/usr/bin/perl

use IO::Handle;

autoflush STDOUT 1;

print "Content-type: text/html\n\n";
my $pid = fork();
if ($pid == 0)
{
print "<p>Hello from child!</p>\n";
sleep(5);
exit;
}
print "<p>Hello from parent</p>\n";
waitpid($pid, 0);
print "<p>Done</p>\n";
--

Waarschijnlijk is het HTTP/1.1 protocol gewoon niet geschikt voor
'tussentijdse updates'

Overigens zie ik nu ook dat de serverpush-methode niet werkt in Safari als
ik text/html als content-type gebruik.

--
robert

Op Wed, 06 Aug 2008 05:48:02 +0000, schreef robert..

> Maar de methode van testen is wel belangrijk:

Natuurlijk, maar in dit geval doe ik het even on-the-fly en met grote
vegen. Er zit nu geen werk aan vast, dit is hobby :-)

> de commandline HTTP client 'curl' laat bij onderstaand script de eerste
> twee regels uitvoer direct zien (zoals je zou verwachten), maar mijn
> browser Safari wacht gewoon totdat de verbinding gesloten wordt en laat
> dan pas, in 1 keer, alle uitvoer zien:

Ik zal Curl eens een keer bekijken.

> -test.pl-

<knip>

> Waarschijnlijk is het HTTP/1.1 protocol gewoon niet geschikt voor
> 'tussentijdse updates'

Hm.. Ik ben van mening dat het geen tussentijdse updates zijn, want de
output is voor de browser gewoon sequentieel. Toch? Dus voor de browser
maakt het IMO niet uit of de Parent, of het Child tegen 'm praat, in
welke volgorde dat ook gebeurt.

> Overigens zie ik nu ook dat de serverpush-methode niet werkt in Safari
> als ik text/html als content-type gebruik.

Ik stap van de browser-side af en ga me verdiepen in zoiets als
Acme::Spork. Ik heb al even een vluchtige blik op de source geworpen en
geloof dat ik 't begin te snappen ;-)

--
Constant change is here to stay

Ronin <ronin@xs4all.invalid>:
> Op Wed, 06 Aug 2008 05:48:02 +0000, schreef robert..
>
>> Waarschijnlijk is het HTTP/1.1 protocol gewoon niet geschikt voor
>> 'tussentijdse updates'
>
> Hm.. Ik ben van mening dat het geen tussentijdse updates zijn, want de
> output is voor de browser gewoon sequentieel. Toch? Dus voor de browser
> maakt het IMO niet uit of de Parent, of het Child tegen 'm praat, in
> welke volgorde dat ook gebeurt.

Klopt, en het probleem dat ik zag blijkt weer ergens anders te zitten.

Ik heb namelijk nog wat verder getest: Safari wacht totdat alle uitvoer
van het script binnen is, en laat dus pas aan het einde van het script
(als zowel child als parent klaar zijn) de uitvoer zien.

Firefox laat de uitvoer van het script zien op het moment dat het print
statement wordt uitgevoerd, en buffert dus niks. Dat is precies wat je
wilde, maar is dus wel enigzins browserafhankelijk.

>> Overigens zie ik nu ook dat de serverpush-methode niet werkt in
>> Safari als ik text/html als content-type gebruik.
>
> Ik stap van de browser-side af en ga me verdiepen in zoiets als
> Acme::Spork. Ik heb al even een vluchtige blik op de source geworpen
> en geloof dat ik 't begin te snappen ;-)

Gisteren liep ik nog tegen Acme::Fork::Lazy aan, dat wellicht ook iets voor
je is.

--
robert

Op Wed, 06 Aug 2008 09:51:22 +0000, schreef robert..

>> Ik stap van de browser-side af en ga me verdiepen in zoiets als
>> Acme::Spork. Ik heb al even een vluchtige blik op de source geworpen en
>> geloof dat ik 't begin te snappen ;-)

> Gisteren liep ik nog tegen Acme::Fork::Lazy aan, dat wellicht ook iets
> voor je is.

Ik geloof dat ik m'n ding heb gevonden. Dit weekend ga ik eens stoeien
met POE (http://poe.perl.org), dat lijkt me, na oppervlakkig scannen
alles te kunnen wat ik nodig heb.

--
Constant change is here to stay