2009-06-07 7 views
2

pourquoi est-il correct pour un lecteur d'exister quand il n'y a pas d'écrivains, mais pas ok pour un écrivain d'exister quand il n'y a pas de lecteurs dans les tuyaux?pourquoi est-il un comportement asymétrique dans les tuyaux

. Est-ce parce que le lecteur est censé attendre, donc c'est bien s'il n'y a pas d'écrivain alors qu'un écrivain est prêt avec les données et on ne sait pas combien de temps il doit attendre même s'il a des données prêtes.

. Est-ce parce que le descripteur de fichier de l'auteur peut être mal utilisé par les lecteurs (je ne suis pas clair comment)

+1

Euh ... un contexte serait bien .... – skaffman

+1

Quel genre de tuyaux parlez-vous? tuyaux de ligne de commande? Des tuyaux nommés? – Eddie

Répondre

0

Dans le cas d'un lecteur, il va bloquer immédiatement (sommeil) parce qu'il n'y a rien à lire. Si l'écrivain commence le lecteur continue à dormir, et aucun mal fait.

Pour un écrivain, il remplirait les tampons et le bloc. Si aucun lecteur n'arrivait, ce serait un pur gaspillage des ressources du système.

FYI, ce qui précède est une supposition éclairée.

1

C'est parce que la condition d'erreur est déclenchée par la sortie. Donc, un lecteur sans écrivain s'assoit juste là, ne dérange pas n'importe quoi, parce qu'il n'y a aucune sortie qui essaye d'aller quelque part et ne peut pas. Un écrivain sans lecteurs tente d'envoyer sa sortie, ne peut pas, et les erreurs.

5

Vous devez parler d'une implémentation spécifique des tuyaux.

[Proc 1] 
$ mkfifo /tmp/mypipe 
$ echo "No Boom Here" > /tmp/mypipe 
<process blocks> 

[Proc 2, later] 

$ cat /tmp/mypipe 
No Boom Here 

Ainsi, il fonctionne très bien sur les systèmes Unix, vous pouvez lire ou écrire un tuyau sans lecteurs ou écrivains. Cependant, votre processus bloquera jusqu'à ce que le compagnon se lève.

Peut-être que ce est une chose Windows?

En aparté, la façon dont Unix est le bon comportement, à mon humble avis. Ça devrait juste bloquer de toute façon.