Vasumathi Sundaram wrote:
> 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.
It would be useful to be more explicit about exactly what is different:
- 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.
That last paragraph might better read:
This function is analogous to the writev(2) system call, but can
read from both buffers and file descriptors. Unlike writev(),
in the case of multiple writers to a file the effect of
sendfilev is not necessarily atomic; the writes may be
interleaved. Application-specific synchronization methods
must be employed if this causes problems.
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
