Je suis en train d'écrire une application Cocoa à un seul thread et j'essaie d'utiliser la méthodologie de l'utilitaire NSNotificationCenter (comme cela semble être le cas dans le cacao) pour faire des E/S non bloquantes.Les appels de fermeture prennent une éternité en utilisant les E/S asynchrones de Cocoa?
Tout semble fonctionner correctement sauf lorsque le handle de fichier est fermé. Il finit par me notifier, mais cela prend une éternité. Quelqu'un peut-il expliquer pourquoi ce serait? Plus précisément, j'écris un économiseur d'écran qui forge un processus et lit sa sortie standard. Le comportement change également en fonction du contexte. Lorsqu'il s'exécute dans la fenêtre de prévisualisation dans les Préférences Système, il notifie à proximité plus rapidement, puis lorsqu'il fonctionne en plein écran en cliquant sur le bouton de test. Edit: Après un peu de réflexion, je crois que le problème est que la dernière écriture et la clôture se produisent à peu près en même temps. La dernière lecture a lieu après que le NSFileHandle a été fermé, et il retourne des données (c'est-à-dire pas à EOF). Je finis par attendre, mais puisque le descripteur de fichier est inactif, la boucle principale restera bloquée car il n'y a rien à signaler pour l'exécuter. La raison pour laquelle le mode de prévisualisation fonctionne est que chaque fois que je clique sur quelque chose dans la fenêtre des Préférences Système, j'exécute la boucle principale et vérifie l'état du NSFileHandle en attente et voit qu'il est fermé.
Maintenant, je pense que je sais ce qui se passe, mais je ne sais toujours pas comment savoir que le NSFileHandle est fermé sans blocage!
Après quelques tests supplémentaires, ce problème semble être exclusif lorsque l'économiseur d'écran est en cours d'exécution.
Lecture après fermeture (en supposant que j'ai déjà lu toutes les données mises en mémoire tampon) retour 0 octets, ce qui signifie EOF. J'utilise 'NSTask' pour bifurquer le processus qui produit trois' NSFileHandle'. Je ne pense pas que 'NSSTream' est ce que je veux, car il semble être exclusivement pour les sockets réseau. – jdizzle
Comment voulez-vous dire "arriver à peu près au même moment"? Voulez-vous dire de différents fils? Aussi ce qui vous fait penser "Lire après la fin retournera 0 octets"? Les docs indiquent clairement qu'il lèvera une exception. –
La dernière écriture et la fermeture proviennent toutes deux d'un processus fils. La lecture après fermeture renvoie 0 octet au moins une fois. C'est comme ça que vous savez que vous êtes à l'EOF. Si vous faites référence à la documentation NSFileHandle, il indique qu'il déclenche une exception si une erreur se produit dans le descripteur de fichier. EOF n'est pas une erreur. – jdizzle