J'ai remarqué quelques bizarreries lorsque vous traitez avec des canaux nommés (Fifo) en vertu de différentes saveurs de UNIX (Linux, FreeBSD et mac os X) à l'aide de Python. La première, et peut-être le plus ennuyeux, c'est que les tentatives d'ouverture de vide/inactif FIFO en lecture seule bloc (à moins que j'utilise os.O_NONBLOCK
avec le niveau inférieur os.open()
appel). Cependant, si je l'ouvre pour lire/écrire alors je n'ai pas de 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 ne l'ouvrez bloc d'appel plutôt que comme une opération de lecture ultérieure?
Aussi j'ai remarqué qu'un non-bloquant descripteur de fichier peut exposer à des comportements différents en Python. Dans le cas où j'utilise os.open()
avec l' os.O_NONBLOCK
pour l'ouverture initiale de l'opération puis un os.read()
semble renvoyer une chaîne vide si les données n'est pas prêt sur le descripteur de fichier. Cependant, si je prends fcntl.fcnt(f.fileno(), fcntl.F_SETFL, fcntl.GETFL | os.O_NONBLOCK)
puis un os.read
lève une exception (errno.EWOULDBLOCK
)
Est-il un autre drapeau a été défini par la normale open()
ce n'est pas m' os.open()
exemple? Comment sont-ils différents et pourquoi?