g****o
发帖数: 1284 | 1 I know in traditional I/O, we usually hire two buffers to handle the I/O
operation: a kernel buffer and a user buffer. If a thread send a read request,
it traps in the kernel and blocks. Data first is transferred from device to
kernel buffer, and from kernel buffer to user buffer at last. After the
transferring is finished, the thread returns from kernel and continue its
execution.
Suppose I want to implement asynchronous I/O like this way: A user lever
thread sends a read request then immediate | t******q
发帖数: 117 | 2 It is belived that the buffered I/O are more effiecent than
the direct unbuffered i/o, since os will schedule the filebuffer -> user
buffer
transfer.
usually, you need to call fflush to make sure the fwrite out the
data from filebuffer to disk. since the schedule thing, it is not
safe to assume the data is out unless you force it write out.
if you fprintf to stdios, sometime you have to fflush the file pointer
to see the output. Maybe that is the reason.
read the FILE structure.
request,
reque
【在 g****o 的大作中提到】
: I know in traditional I/O, we usually hire two buffers to handle the I/O
: operation: a kernel buffer and a user buffer. If a thread send a read request,
: it traps in the kernel and blocks. Data first is transferred from device to
: kernel buffer, and from kernel buffer to user buffer at last. After the
: transferring is finished, the thread returns from kernel and continue its
: execution.
: Suppose I want to implement asynchronous I/O like this way: A user lever
: thread sends a read request then immediate
| p******f
发帖数: 162 | 3 you answered the wrong questions.
【在 t******q 的大作中提到】
: It is belived that the buffered I/O are more effiecent than
: the direct unbuffered i/o, since os will schedule the filebuffer -> user
: buffer
: transfer.
: usually, you need to call fflush to make sure the fwrite out the
: data from filebuffer to disk. since the schedule thing, it is not
: safe to assume the data is out unless you force it write out.
: if you fprintf to stdios, sometime you have to fflush the file pointer
: to see the output. Maybe that is the reason.
: read the FILE structure.
| c********e
发帖数: 417 | 4 There should be a way to do direct I/O. The kernel locks (after page-in
if necessary) the user buffer and pass the S/G list to device driver.
【在 g****o 的大作中提到】
: I know in traditional I/O, we usually hire two buffers to handle the I/O
: operation: a kernel buffer and a user buffer. If a thread send a read request,
: it traps in the kernel and blocks. Data first is transferred from device to
: kernel buffer, and from kernel buffer to user buffer at last. After the
: transferring is finished, the thread returns from kernel and continue its
: execution.
: Suppose I want to implement asynchronous I/O like this way: A user lever
: thread sends a read request then immediate
|
|
