> Sorry, I still don't see the difference between your completion ports
> and event queues. In both cases, as far as I can tell, when I/O
> completes a "message" is sent to some place. The application can then
> pick off these events. Part of the message includes the FD which had
> the completed I/O.
completion port:
1. write(FD, buf, 16384) ==> returns some code indicating I/O in progress
2. some time later all 16384 bytes are written (or error occurs)
3. app gets a completion event from the port
select/poll:
1. write(FD, buf, 16384) ==> 4096
2. write(FD, buf+4096, 12288) ==> EWOULDBLOCK
3. put FD into poll/select sets
4. some time later poll/select indicates ready for write
5. go back to 1, try to write more from buf
readiness queue:
1. write(FD, buf, 16384) ==> 4096
2. write(FD, buf+4096, 12288) ==> EWOULDBLOCK
3. at this point the kernel notes that you've been told EWOULDBLOCK,
and when it's ready for write on FD it will have to send you a
readiness event
4. some time later get readiness event from event queue
5. go back to 1, try to write more from buf
In the completion port case the kernel has done all the work of
"completing" the request. In the other two cases the kernel only does
the work of saying "I'm ready for another write/read", no indication of
how much progress you'll make.
Notice the similarity between select/poll and readiness queue ... the
only difference is how the kernel is asked to tell you of readiness.
For the readiness queue we've presumably done an ioctl() on FD earlier
on telling the kernel to do this special processing on EWOULDBLOCK.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu