[swift-corelibs-dev] [swift-corelibs-libdispatch] Support for file readahead under linux using readahead (#39)

[Pierre Habouzit]

> 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.

-Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160128/46caf268/attachment.html>