This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FreeBSD port (29): sendfile


Bruno Haible <bruno@clisp.org> writes:

> Hi,
> 
> Since FreeBSD's native sendfile() system call is not the same as the Linux
> one (works only on sockets), here is a patch that adds an emulation of it
> using read/write to sysdeps/posix/.

 The Linux one has limitations as well (for example you cannot
currently sendfile() with a src of a TCP socket and a dst of a local
file). The interface for telling you something is wrong is return -1,
errno = EINVAL.
 The only other difference is the addition of iovec's at the beginning
and the end ... and that is worthless and can be just ignored.

 For autoconf on projects I've used...

#ifndef HAVE_SENDFILE
ssize_t FIX_SYMBOL(sendfile)(int out_fd, int in_fd,
                             off_t *offset, size_t nbytes)
{
#ifdef HAVE_FREEBSD_SENDFILE
 ssize_t ret = 0;

 /* don't get caught by the #define sendfile ... butcher all the arguments */
 ret = (sendfile)(in_fd, out_fd, offset ? *offset : 0, nbytes, NULL,
                  offset, 0);
 return (ret);
#else
 errno = EINVAL; /* pretend the in_fd isn't in the page cache in Linux
                  * as they have to fall back to read()/write() in that case
                  * anyway */
 return (-1);
#endif
}
#endif

> The emulation is multithread-safe if the platform has a pread() system call,
> like FreeBSD does, otherwise it is not multithread-safe (but better than
> the stub in sysdeps/generic).

 No it isn't, it's completely broken. If you pass NULL as the off_t
then it's supposed to use the off_t associated with the fd (just like
read and write) ... your version will just silently drop data when
reading from a non-file as the src.
 Just returning ENOSYS, would be _much_ better.

-- 
James Antill -- james@and.org
The Hurd itself is aggressively multi-threaded and all of the locking has
been done with an eye towards multi-processor systems. That said, we have
not yet used a microkernel that stably supports multiple cpus.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]