IP Girl
  1. IP Girl
  3. Pourquoi une lecture seule ouvre-t-elle un bloc de canaux nommé?
Intereting Posts
Pouvez-vous avoir un sortingple moins de signes en programmation C? Qu’est-ce que ça veut dire? Reporting Services: RepeatTolumnHeaders Tablix ne fonctionne pas sur certains rapports Fichier de couverture de l’application de routage Que puis-je faire avec mon code scala pour qu’il comstack plus rapidement? Comment détecter la fin du chargement de UITableView Pourquoi d’autres méthodes peuvent-elles être «statiques», mais pas un constructeur? L’exécution de karma après l’installation entraîne la création d’un “karma” qui n’est pas reconnu comme une commande interne ou externe transférer db d’une application heroku à une autre plus rapidement Sublime Text regex ne détecte pas les balises multilignes Y a-t-il un moyen de mesurer le classement d’une liste? Comment définir ObjectId comme type de données dans mongoose Quel est le meilleur environnement Ruby on Rails pour un utilisateur de Visual Studio? Comment puis-je traiter chaque lettre de texte avec Javascript? Puis-je utiliser Twitter Bootstrap et jQuery UI en même temps? Comment puis-je obtenir le nom d’utilisateur actuel dans .NET en utilisant C #?

Pourquoi une lecture seule ouvre-t-elle un bloc de canaux nommé?

J’ai remarqué quelques bizarreries avec les FIFO nommés sous différentes versions d’UNIX (Linux, FreeBSD et MacOS X) utilisant Python. Le premier, et peut-être le plus ennuyeux, est que les tentatives d’ouverture d’une FIFO vide / inactive en lecture seule vont bloquer (sauf si j’utilise os.O_NONBLOCK avec l’appel os.open() niveau inférieur). Cependant, si je l’ouvre pour lire / écrire, je n’ai aucun blocage.

Exemples: 

 f = open('./myfifo', 'r') # Blocks unless data is already in the pipe f = os.open('./myfifo', os.O_RDONLY) # ditto # Contrast to: f = open('./myfifo', 'w+') # does NOT block f = os.open('./myfifo', os.O_RDWR) # ditto f = os.open('./myfifo', os.O_RDONLY|os.O_NONBLOCK) # ditto

Je suis juste curieux de savoir pourquoi. Pourquoi l’appel ouvert bloque-t-il plutôt qu’une opération de lecture ultérieure?

J’ai également remarqué qu’un descripteur de fichier non bloquant peut présenter différents comportements en Python. Dans le cas où j’utilise os.open() avec os.O_NONBLOCK pour l’opération d’ouverture initiale, un os.read() semble renvoyer une chaîne vide si les données ne sont pas prêtes sur le descripteur de fichier. Cependant, si j’utilise fcntl.fcnt(f.fileno(), fcntl.F_SETFL, fcntl.GETFL | os.O_NONBLOCK) un os.read déclenche une exception ( errno.EWOULDBLOCK )

Y a-t-il un autre drapeau défini par le open() normal qui n’est pas défini dans mon exemple os.open() ? Comment sont-ils différents et pourquoi?

C’est comme ça que c’est défini. De la page Open Group pour la fonction open() 

 O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set: If O_NONBLOCK is set: An open() for reading only will return without delay. An open() for writing only will return an error if no process currently has the file open for reading. If O_NONBLOCK is clear: An open() for reading only will block the calling thread until a thread opens the file for writing. An open() for writing only will block the calling thread until a thread opens the file for reading.