avatar
I/O implementation question# Unix - 噫吁兮,危乎高哉
g*o
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
avatar
t*q
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

avatar
p*f
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.

avatar
c*e
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

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。