| … | |
… | |
| 359 | reading at byte offset $in_offset, and starts writing at the current |
359 | reading at byte offset $in_offset, and starts writing at the current |
| 360 | file offset of $out_fh. Because of that, it is not safe to issue |
360 | file offset of $out_fh. Because of that, it is not safe to issue |
| 361 | more than one "aio_sendfile" per $out_fh, as they will interfere |
361 | more than one "aio_sendfile" per $out_fh, as they will interfere |
| 362 | with each other. |
362 | with each other. |
| 363 | |
363 | |
|
|
364 | Please note that "aio_sendfile" can read more bytes from $in_fh than |
|
|
365 | are written, and there is no way to find out how many bytes have |
|
|
366 | been read from "aio_sendfile" alone, as "aio_sendfile" only provides |
|
|
367 | the number of bytes written to $out_fh. Only if the result value |
|
|
368 | equals $length one can assume that $length bytes have been read. |
|
|
369 | |
|
|
370 | Unlike with other "aio_" functions, it makes a lot of sense to use |
|
|
371 | "aio_sendfile" on non-blocking sockets, as long as one end |
|
|
372 | (typically the $in_fh) is a file - the file I/O will then be |
|
|
373 | asynchronous, while the socket I/O will be non-blocking. Note, |
|
|
374 | however, that you can run into a trap where "aio_sendfile" reads |
|
|
375 | some data with readahead, then fails to write all data, and when the |
|
|
376 | socket is ready the next time, the data in the cache is already |
|
|
377 | lost, forcing "aio_sendfile" to again hit the disk. Explicit |
|
|
378 | "aio_read" + "aio_write" let's you control resource usage much |
|
|
379 | better. |
|
|
380 | |
| 364 | This call tries to make use of a native "sendfile" syscall to |
381 | This call tries to make use of a native "sendfile" syscall to |
| 365 | provide zero-copy operation. For this to work, $out_fh should refer |
382 | provide zero-copy operation. For this to work, $out_fh should refer |
| 366 | to a socket, and $in_fh should refer to an mmap'able file. |
383 | to a socket, and $in_fh should refer to an mmap'able file. |
| 367 | |
384 | |
| 368 | If a native sendfile cannot be found or it fails with "ENOSYS", |
385 | If a native sendfile cannot be found or it fails with "ENOSYS", |
| 369 | "ENOTSUP", "EOPNOTSUPP", "EAFNOSUPPORT", "EPROTOTYPE" or "ENOTSOCK", |
386 | "ENOTSUP", "EOPNOTSUPP", "EAFNOSUPPORT", "EPROTOTYPE" or "ENOTSOCK", |
| 370 | it will be emulated, so you can call "aio_sendfile" on any type of |
387 | it will be emulated, so you can call "aio_sendfile" on any type of |
| 371 | filehandle regardless of the limitations of the operating system. |
388 | filehandle regardless of the limitations of the operating system. |
| 372 | |
|
|
| 373 | Please note, however, that "aio_sendfile" can read more bytes from |
|
|
| 374 | $in_fh than are written, and there is no way to find out how many |
|
|
| 375 | bytes have been read from "aio_sendfile" alone, as "aio_sendfile" |
|
|
| 376 | only provides the number of bytes written to $out_fh. Only if the |
|
|
| 377 | result value equals $length one can assume that $length bytes have |
|
|
| 378 | been read. |
|
|
| 379 | |
389 | |
| 380 | aio_readahead $fh,$offset,$length, $callback->($retval) |
390 | aio_readahead $fh,$offset,$length, $callback->($retval) |
| 381 | "aio_readahead" populates the page cache with data from a file so |
391 | "aio_readahead" populates the page cache with data from a file so |
| 382 | that subsequent reads from that file will not block on disk I/O. The |
392 | that subsequent reads from that file will not block on disk I/O. The |
| 383 | $offset argument specifies the starting point from which data is to |
393 | $offset argument specifies the starting point from which data is to |
