This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: FreeBSD port (29): sendfile
- From: James Antill <james at and dot org>
- To: Bruno Haible <bruno at clisp dot org>
- Cc: libc-alpha at sources dot redhat dot com
- Date: 12 Jul 2002 15:47:31 -0400
- Subject: Re: FreeBSD port (29): sendfile
- References: <15662.48929.757288.577532@honolulu.ilog.fr>
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.