c++ - SetFileCompletionNotificationModes seems to not work properly -

i'm using setfilecompletionnotificationmodes() api optimize i/o completion ports loops, seems not work properly. if set file_skip_completion_port_on_success sockets , handles, i/o port's completion callback still called if readfile() writefile() wsarecv() wsasend() return synchronosly.

i'm sure 3 conditions msdn says must true (a completion port associated file handle, file opened asynchronous i/o, request returns success without returning error_pending) met, , true, why still receive i/o completion calls?

when call setfilecompletionnotificationmodes() returns success, no errors or whatsoever, , system windows 7.

how can replicate scenario when after have activated setfilecompletionnotificationmodes() on socket/handles, can see i/o completion callback won't called?

i guessed happens when write few bytes on socket, since socket's buffer quite bigger, didn't full it, write of few bytes shouldn't block, since there still lot of room in buffer, should return immediately, not error_io_pending, in synchronous way, right? (more or less, in similar way of unix ewouldblock/eagain: when call write() few bytes returns immediately, , doesn't return eagain, because there still space in write buffer).

well doesn't that. writing multiple times few bytes on socket, still calls i/o completion callback, avoding benefits of setting file_skip_completion_port_on_success

am missing important? clue that?

note: know wont work if socket compatible layered service providers (lsp) return installable file systems (ifs) handles, that's not case, should work. btw i'm trying pipes , files.

shouldn't files never call i/o completion callbacks because never block, in unix read() , write() calls on local files never returns ewouldblock/eagain, readfile() , writefile() handle set file_skip_completion_port_on_success should return immediately?

a network write completion generated when data buffer have provided no longer required network stack. it's hard reason when , it's irrelevant , not worry about. when issue overlapped write file_skip_completion_port_on_success set write operation return 0 if , if completion has occurred synchronously. write code handle case correctly (it's same code need recv side) , forget it. you'll performance , context switching advantages when it's possible , code work correctly when isn't.

as file system access, depends on file system drivers and, actual hardware. see here information how hard can hardware async file writes @ all, ever. note when switched test talk there workstation 'normal' sata disks server hardware raid different , of writes async...