| … | |
… | |
| 168 | use common::sense; |
168 | use common::sense; |
| 169 | |
169 | |
| 170 | use base 'Exporter'; |
170 | use base 'Exporter'; |
| 171 | |
171 | |
| 172 | BEGIN { |
172 | BEGIN { |
| 173 | our $VERSION = '3.93'; |
173 | our $VERSION = '4.0'; |
| 174 | |
174 | |
| 175 | our @AIO_REQ = qw(aio_sendfile aio_read aio_write aio_open aio_close |
175 | our @AIO_REQ = qw(aio_sendfile aio_read aio_write aio_open aio_close |
| 176 | aio_stat aio_lstat aio_unlink aio_rmdir aio_readdir aio_readdirx |
176 | aio_stat aio_lstat aio_unlink aio_rmdir aio_readdir aio_readdirx |
| 177 | aio_scandir aio_symlink aio_readlink aio_realpath aio_sync aio_fsync |
177 | aio_scandir aio_symlink aio_readlink aio_realpath aio_sync aio_fsync |
| 178 | aio_fdatasync aio_sync_file_range aio_fallocate |
178 | aio_fdatasync aio_sync_file_range aio_fallocate |
| … | |
… | |
| 1804 | =head2 FORK BEHAVIOUR |
1804 | =head2 FORK BEHAVIOUR |
| 1805 | |
1805 | |
| 1806 | Usage of pthreads in a program changes the semantics of fork |
1806 | Usage of pthreads in a program changes the semantics of fork |
| 1807 | considerably. Specifically, only async-safe functions can be called after |
1807 | considerably. Specifically, only async-safe functions can be called after |
| 1808 | fork. Perl doesn't know about this, so in general, you cannot call fork |
1808 | fork. Perl doesn't know about this, so in general, you cannot call fork |
| 1809 | with defined behaviour in perl. IO::AIO uses pthreads, so this applies, |
1809 | with defined behaviour in perl if pthreads are involved. IO::AIO uses |
| 1810 | but many other extensions and (for inexplicable reasons) perl itself often |
1810 | pthreads, so this applies, but many other extensions and (for inexplicable |
| 1811 | is linked against pthreads, so this limitation applies. |
1811 | reasons) perl itself often is linked against pthreads, so this limitation |
|
|
1812 | applies to quite a lot of perls. |
| 1812 | |
1813 | |
| 1813 | Some operating systems have extensions that allow safe use of fork, and |
1814 | This module no longer tries to fight your OS, or POSIX. That means IO::AIO |
| 1814 | this module should do "the right thing" on those, and tries on others. At |
1815 | only works in the process that loaded it. Forking is fully supported, but |
| 1815 | the time of this writing (2011) only GNU/Linux supports these extensions |
1816 | using IO::AIO in the child is not. |
| 1816 | to POSIX. |
1817 | |
|
|
1818 | You might get around by not I<using> IO::AIO before (or after) |
|
|
1819 | forking. You could also try to call the L<IO::AIO::reinit> function in the |
|
|
1820 | child: |
|
|
1821 | |
|
|
1822 | =over 4 |
|
|
1823 | |
|
|
1824 | =item IO::AIO::reinit |
|
|
1825 | |
|
|
1826 | Abondons all current requests and I/O threads and simply reinitialises all |
|
|
1827 | data structures. This is not an operation suppported by any standards, but |
|
|
1828 | happens to work on GNU/Linux and some newer BSD systems. |
|
|
1829 | |
|
|
1830 | The only reasonable use for this function is to call it after forking, if |
|
|
1831 | C<IO::AIO> was used in the parent. Calling it while IO::AIO is active in |
|
|
1832 | the process will result in undefined behaviour. Calling it at any time |
|
|
1833 | will also result in any undefined (by POSIX) behaviour. |
|
|
1834 | |
|
|
1835 | =back |
| 1817 | |
1836 | |
| 1818 | =head2 MEMORY USAGE |
1837 | =head2 MEMORY USAGE |
| 1819 | |
1838 | |
| 1820 | Per-request usage: |
1839 | Per-request usage: |
| 1821 | |
1840 | |
