l=[ # une liste d'instance de Titre # ]
for t in l:
t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un
programme (ezsteam [1])
J'ai un souci avec ce truc:
Si je fais un sys.stdout.flush() ou un fd.close() apres le
sys.stdout.write(fd.read) alors le stream est merdique: le sont est
haché, l'enchainement des titres est mal fait et des fois il perd le
tunnel (broken pipe) .
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à streamer
est correct.
J'ai un petit millier de fichier à streamer en fonction de l'heure et
tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose.
De plus, si le serveur est surchargé au niveau CPU, par un autre thread
python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il
casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun
calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne marche
pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast]
[2
http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation/
]
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1])
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à stre amer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquech ose. De plus, si le serveur est surchargé au niveau CPU, par un autre thre ad python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a au cun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne mar che pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation / ]
Merci.
Je viens de lire et une remarque tu ne test jamais la fin de la
consommation du pipe par le client. Donc si tu fais un fd.close et que tu recharge le pipe tu peux perdre des informations qui sont encore dans le tampon du pipe.
Enfin je verrais bien un truc comme ça ... Peut être devrais tu gérer une file d'attente/buffer à l'intérieu r de ton script Python.
-- Un blog sur les pages persos de wanadoo ? chtioblogue : http://perso.wanadoo.fr/bertrand.belguise/blog/blog.html (Totalement client-side sans php ni base de donnée)
l=[ # une liste d'instance de Titre # ]
for t in l:
t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un
programme (ezsteam [1])
J'ai un souci avec ce truc:
Si je fais un sys.stdout.flush() ou un fd.close() apres le
sys.stdout.write(fd.read) alors le stream est merdique: le sont est
haché, l'enchainement des titres est mal fait et des fois il perd le
tunnel (broken pipe) .
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à stre amer
est correct.
J'ai un petit millier de fichier à streamer en fonction de l'heure et
tout, et je crois bien que si je ne fd.close() pas, je risque quelquech ose.
De plus, si le serveur est surchargé au niveau CPU, par un autre thre ad
python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il
casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a au cun
calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne mar che
pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast]
[2
http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation /
]
Merci.
Je viens de lire et une remarque tu ne test jamais la fin de la
consommation du pipe par le client. Donc si tu fais un fd.close et que
tu recharge le pipe tu peux perdre des informations qui sont encore dans
le tampon du pipe.
Enfin je verrais bien un truc comme ça ...
Peut être devrais tu gérer une file d'attente/buffer à l'intérieu r de
ton script Python.
--
Un blog sur les pages persos de wanadoo ?
chtioblogue : http://perso.wanadoo.fr/bertrand.belguise/blog/blog.html
(Totalement client-side sans php ni base de donnée)
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1])
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à stre amer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure et tout, et je crois bien que si je ne fd.close() pas, je risque quelquech ose. De plus, si le serveur est surchargé au niveau CPU, par un autre thre ad python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a au cun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne mar che pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmation / ]
Merci.
Je viens de lire et une remarque tu ne test jamais la fin de la
consommation du pipe par le client. Donc si tu fais un fd.close et que tu recharge le pipe tu peux perdre des informations qui sont encore dans le tampon du pipe.
Enfin je verrais bien un truc comme ça ... Peut être devrais tu gérer une file d'attente/buffer à l'intérieu r de ton script Python.
-- Un blog sur les pages persos de wanadoo ? chtioblogue : http://perso.wanadoo.fr/bertrand.belguise/blog/blog.html (Totalement client-side sans php ni base de donnée)
Bertrand B
Bonjour,
J'ai un script python, qui fait un [...] class Titre: def __init__(self,p): self.path=p def prout(self): fd=open(self.path,"rb") sys.stdout.write(fd.read) [...]
Plus bas je fais ceci:
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1])
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à str eamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure e t tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose. De plus, si le serveur est surchargé au niveau CPU, par un autre thr ead python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne ma rche pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmatio n/ ]
Merci.
Je viens de lire et une remarque tu ne test jamais la fin de la
consommation du pipe par le client. Donc si tu fais un fd.close et que tu recharge le pipe tu peux perdre des informations qui sont encore dan s le tampon du pipe.
Enfin je verrais bien un truc comme ça ... Peut être devrais tu gérer une file d'attente/buffer à l'intéri eur de ton script Python.
Et après y avoir réfléchi une solution moins lourde serait de trava iller
avec un pool de 2 file descriptor et faire le close du fd juste avant l'open ce qui permettrait de ne fermer qu'après être sur que le fichier aura été complètement p ousser dans le pipe puisque le transfert du deuxième fichier aura bien commenc é (puisque théoriquement fini).
(pas clair ... tordu ... ouais)
-- Un blog sur les pages persos de wanadoo ? chtioblogue : http://perso.wanadoo.fr/bertrand.belguise/blog/blog.html (Totalement client-side sans php ni base de donnée)
Bonjour,
J'ai un script python, qui fait un
[...]
class Titre:
def __init__(self,p):
self.path=p
def prout(self):
fd=open(self.path,"rb")
sys.stdout.write(fd.read)
[...]
Plus bas je fais ceci:
l=[ # une liste d'instance de Titre # ]
for t in l:
t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un
programme (ezsteam [1])
J'ai un souci avec ce truc:
Si je fais un sys.stdout.flush() ou un fd.close() apres le
sys.stdout.write(fd.read) alors le stream est merdique: le sont est
haché, l'enchainement des titres est mal fait et des fois il perd le
tunnel (broken pipe) .
Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à str eamer
est correct.
J'ai un petit millier de fichier à streamer en fonction de l'heure e t
tout, et je crois bien que si je ne fd.close() pas, je risque
quelquechose.
De plus, si le serveur est surchargé au niveau CPU, par un autre thr ead
python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il
casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a
aucun
calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne ma rche
pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast]
[2
http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmatio n/
]
Merci.
Je viens de lire et une remarque tu ne test jamais la fin de la
consommation du pipe par le client. Donc si tu fais un fd.close et que
tu recharge le pipe tu peux perdre des informations qui sont encore dan s
le tampon du pipe.
Enfin je verrais bien un truc comme ça ...
Peut être devrais tu gérer une file d'attente/buffer à l'intéri eur de
ton script Python.
Et après y avoir réfléchi une solution moins lourde serait de trava iller
avec un pool de 2 file descriptor
et faire le close du fd juste avant l'open ce qui permettrait de ne
fermer qu'après être sur que le fichier aura été complètement p ousser
dans le pipe puisque le transfert du deuxième fichier aura bien commenc é
(puisque théoriquement fini).
(pas clair ... tordu ... ouais)
--
Un blog sur les pages persos de wanadoo ?
chtioblogue : http://perso.wanadoo.fr/bertrand.belguise/blog/blog.html
(Totalement client-side sans php ni base de donnée)
J'ai un script python, qui fait un [...] class Titre: def __init__(self,p): self.path=p def prout(self): fd=open(self.path,"rb") sys.stdout.write(fd.read) [...]
Plus bas je fais ceci:
l=[ # une liste d'instance de Titre # ] for t in l: t.prout()
Le fichier est une vidéo theora qu'on doit balancer au stdin d'un programme (ezsteam [1])
J'ai un souci avec ce truc: Si je fais un sys.stdout.flush() ou un fd.close() apres le sys.stdout.write(fd.read) alors le stream est merdique: le sont est haché, l'enchainement des titres est mal fait et des fois il perd le tunnel (broken pipe) . Pourtant, si je ne fd.close() pas, l'enchainement des fichiers à str eamer est correct. J'ai un petit millier de fichier à streamer en fonction de l'heure e t tout, et je crois bien que si je ne fd.close() pas, je risque quelquechose. De plus, si le serveur est surchargé au niveau CPU, par un autre thr ead python qui n'a rien à voir (l'usine à gaz du site Zope/CPS), alors il casse la pipe (broken pipe)... je ne comprend pas pourquoi, il n'y a aucun calcul à faire, juste faire un prout()...
Voici [2] le code du script, syntaxiquement coloré (le preview ne ma rche pas, faut le downloader) .
[1 C'est ezstream qui ensuite l'envoie à un serveur icecast] [2 http://www.rktmb.org/workspaces/members/mihamina/telegasy-programmatio n/ ]
Merci.
Je viens de lire et une remarque tu ne test jamais la fin de la
consommation du pipe par le client. Donc si tu fais un fd.close et que tu recharge le pipe tu peux perdre des informations qui sont encore dan s le tampon du pipe.
Enfin je verrais bien un truc comme ça ... Peut être devrais tu gérer une file d'attente/buffer à l'intéri eur de ton script Python.
Et après y avoir réfléchi une solution moins lourde serait de trava iller
avec un pool de 2 file descriptor et faire le close du fd juste avant l'open ce qui permettrait de ne fermer qu'après être sur que le fichier aura été complètement p ousser dans le pipe puisque le transfert du deuxième fichier aura bien commenc é (puisque théoriquement fini).
(pas clair ... tordu ... ouais)
-- Un blog sur les pages persos de wanadoo ? chtioblogue : http://perso.wanadoo.fr/bertrand.belguise/blog/blog.html (Totalement client-side sans php ni base de donnée)
