Quando vengono IO pacchetti di porta di completamento inviati e quando no?

Question

Al momento sto lavorando su un meccanismo IPC sulla base di named pipe che utilizzano una porta di completamento IO.

Purtroppo ho alcuni problemi con la documentazione MSDN perché è abbastanza chiaro per me in quali casi le chiamate al risultato ReadFile / WriteFile in un pacchetto di completamento.

Il caso in cui FALSE viene restituito con ERROR_IO_PENDING è chiaro, ma per quanto riguarda l'apparenza possibile caso, quando ERROR_MORE_DATA viene restituito? Ci sarà un pacchetto di completamento in questo caso? Inoltre, ciò che se gli altri errori vengono restituiti? In quali casi devo gestire il risultato e risorse gratuite direttamente e non nel gestore di completamento?

Un altro caso sarebbe se ReadFile / WriteFile anche avere successo, che è apparentemente possibile, anche. MSDN è fortunatamente abbastanza chiaro su questo qui :

  

Inoltre, la funzione WriteFile talvolta restituire TRUE con un valore di GetLastError ERROR_SUCCESS, anche se utilizza un manico asincrono (che può anche restituire FALSE con ERROR_IO_PENDING). ... In questo esempio, la raccomandazione sarebbe quello di permettere la routine di porta di completamento di essere l'unico responsabile di tutte le operazioni liberando di tali risorse.

E 'questa raccomandazione corretta in tutti i casi, e il risultato di un'operazione ReadFile / WriteFile per le maniglie assegnati a una porta di completamento potrebbe (e dovrebbe) in effetti essere ignorato completamente, perché un pacchetto viene inviato alla porta comunque?

Answer 1

Ci sarà un elemento di completamento IO coda per un'operazione IO ogni volta che l'operazione IO è in grado di avviare. Indipendentemente dal fatto che si verifica un errore o meno dopo l'operazione inizia IO, un elemento di completamento sarà in coda alla porta di completamento.

C'è un problema mapping tra i codici NTSTATUS restituiti dal sistema IO e codici di errore Win32 che rende difficile dire che cosa sono stati gli errori e che sono solo informativo. NTSTATUS, che viene utilizzato dal kernel e le API native, ha quattro livelli di gravità: il successo, informazioni, avviso e di errore. Tutt'altro che un codice di errore potrebbe indicare che l'operazione IO è stato in grado di avviare. Win32 ha un solo gravità (ERROR_*), in modo che i codici di successo, di informazione e di allarme dovevano essere mappato a fianco dei codici di errore.

• ERROR_IO_PENDING - STATUS_PENDING è uno status successo
• ERROR_MORE_DATA - STATUS_BUFFER_OVERFLOW un avvertimento o STATUS_MORE_ENTRIES uno stato di successo

È possibile ignorare i codici di errore non che ReadFile o WriteFile ritorno e si aspettano un elemento di completamento in coda, ma la determinazione che è che può essere un po 'di dolore. Sarebbe bello se i codici di errore Win32 erano meglio organizzati, ma Microsoft non fornire una mappatura da NTSTATUS a codici di errore Win32: http://support.microsoft.com/kb/113996 . Vedere ntstatus.h nel SDK piattaforma o l'installazione di VS per determinare quali la gravità di un codice NTSTATUS è.

E 'possibile per l'operazione IO completato quando l'originale chiamata restituisce API, ad esempio una richiesta di lettura che è stato appena copiato dalla cache (niente a che attendere il modo asincrono). Un messaggio di completamento sarà ancora in coda in questi casi per l'amor di coerenza.

Answer 2

• Sì, è del tutto possibile che ERROR_MORE_DATA poteva venire in un pacchetto di completamento. Si dovrebbe sempre essere preparati a gestire eventuali errori. Nella documentazione per GetQueuedCompletionStatus è Chiaro che quando ritorna FALSE, si dovrebbe verificare se il parametro è lpOverlapped NULL. Se non lo è NULL, il completamento del pacchetto di I / O contiene un errore.

• Il comportamento predefinito è per un pacchetto di completamento sia in coda alla porta di completamento anche quando ReadFile o WriteFile ritorno TRUE. A partire da Windows Vista, questa politica può essere modificata. Vedere la documentazione sul SetFileCompletionNotificationModes .