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.
On Jan 28, 2016, at 8:27 AM, Hubertus Franke <email@example.com> wrote:
> @@ -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>.