Yes, this is an actual change. We want to remove an existing lock on the
destination descriptor that is now held for the duration of the system
call. This is the reason for deadlock issues.
Brian Utterback wrote:
> 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 {
>>
>>
>
