[swift-corelibs-dev] [swift-corelibs-libdispatch] Support for file readahead under linux using readahead (#39)
phabouzit at apple.com
Thu Jan 28 10:51:19 CST 2016
> On Jan 28, 2016, at 8:27 AM, Hubertus Franke <notifications at github.com> wrote:
> In src/io.c <https://github.com/apple/swift-corelibs-libdispatch/pull/39#discussion_r51145862>:
> > @@ -2088,6 +2093,14 @@ _dispatch_operation_advise(dispatch_operation_t op, size_t chunk_size)
> > }
> > advise.ra_offset = op->advise_offset;
> > op->advise_offset += advise.ra_count;
> > +#ifdef __linux__
> > + _dispatch_io_syscall_switch(err,
> > + readahead(op->fd_entry->fd, advise.ra_offset, advise.ra_count),
> > + case EBADF: break; // bad file desciptor
> I mean both should NOT be ignored and caught by dispatch_assume_zero()
> Reply to this email directly or view it on GitHub <https://github.com/apple/swift-corelibs-libdispatch/pull/39/files#r51145862>.
Not sure where the pull request went, but you have to ignore EINVAL because when a dispatch_io is created the developer doesn’t *know* that this file-descriptor type doesn’t have kernel support for readahead() so it’s fine, it is NOT a programmer error, he can’t possibly know. This is ENOTSUP for the radvise call on OS X and is ignored.
EBADF is different because it means the underlying fd was closed under dispatch_io feet, or a non open one was passed or something similar which *is* a programmer error.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-corelibs-dev