apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Portability of apr_file_writev_full?
Date Thu, 10 Mar 2005 15:01:37 GMT
apreq has a similar function, and some questions
came up yesterday regarding its implementation. So
I took a look at the recent apr implementation,
and I have a few questions of my own regarding this loop:

    do {
        apr_size_t i, amt;
        status = apr_file_writev(thefile, vec, nvec, &amt);
       /* We assume that writev will only write complete iovec areas.
        * Incomplete writes inside a single area are not supported.
        * This should be safe according to SuS v2. 
        for (i = 0; i < nvec; i++) {
            total += vec[i].iov_len;
            if (total >= amt) {
                vec = &vec[i+1];
                nvec -= i+1;
    } while (status == APR_SUCCESS && nvec > 0);

First, this is the only implementation I could find in apr,
so I assume its being used on non-unix platforms where SuS v2
does not apply, particularly wrt writev() itself.

Second, I disagree that SuS v2 makes any guarantees about writev()
only writing "complete iovec areas".  I assume a conforming writev() 
implementation can hand the single-iovec case off to write().  So if 
there's more data in the iovec than the target device can accept,
it winds up doing a partial write, successfully.  

IMO the statement in SuS: "the writev() function shall always write a 
complete area before proceeding to the next" should be interpreted
conservatively: the implementation isn't allowed to move on to the
next iovec, unless it can write all of the current one.

Joe Schaefer

View raw message