Is this an actual change? It looks to me that it is only a documentation
change. Or is it the case that the intention is to remove some existing
locks since they don't work anyway?
James Carlson wrote:
> I am sponsoring this fast-track request for Vasumathi Sundaram. The
> timer is set to 01/02/2009 in light of the coming holidays. Please
> speak up if you need more time than that.
>
> In an offline discussion, the project team went to lengths to find any
> sendfilev users, and determine whether the proposed change in
> semantics would affect any application. There are just a few known
> users of sendfilev, and none of them do file-to-file transfers, so no
> problems are known or expected.
>
> It's an incompatible change to a Committed interface and we wish to
> assert Patch/Micro release binding, but the project team contends (and
> I agree) that (a) the original interface as specified has unresolvable
> defects that could lead to serious system stability problems, (b) we
> can't just remove the sendfilev interface because there are consumers,
> and (c) it appears unlikely that anyone ever used the functionality
> affected by this change as described.
>
>
> 1. Problem
>
> sendfilev(3EXT) and sendfile(2) support transferring data from a
> regular file to another regular file, in addition to being able to
> transfer to a socket. The current man page states that the
> semantics of this function is analogous to writev(2), except that
> sendfilev can read from data buffers or file descriptors.
>
> Supporting this semantic, however, leads to unavoidable deadlock and
> performance issues.
>
> 2. Solution
>
> sendfilev is modified so that the output behavior is not the same as
> writev() and when multiple threads attempt to write to the same
> output file at the same time. Instead, the result of the combined
> operations is undefined. The applications that use sendfilev() will
> have to use their own synchronization mechanism to ensure a
> consistent output.
>
> 3. Man page update
>
> The following change will be made to the man page of sendfilev(3EXT).
>
> --- sendfilev.old Thu Dec 18 15:41:16 2008
> +++ sendfilev.new Thu Dec 18 15:45:40 2008
> @@ -44,12 +44,6 @@
> open for writing.
>
>
> - This function is analogous to the writev() system call. See
> - writev(2). Instead of sending out chunks of data, however,
> - the sendfilev() function can read input data from data
> - buffers or file descriptors.
> + This function is analogous to the writev(2) system call, but can
> + read from both buffers and file descriptors. Unlike writev(),
> + it does not provide protection against multiple writers on a
> + single stream or file. Applications must use their own
> + synchronization mechanisms if such a situation is possible.
>
> The following is the sendfilevec structure:
>
> typedef struct sendfilevec {
>
>
