At 12:52 PM 10/25/2002, Bill Stoddard wrote: >The point of my comment was that this is irrelevant for what I am interested >in talking about. > >But since we are on the topic... APR_XTHREAD implies the file needs to be >opened for overlapped i/o. Files opened for overlapped i/o don't HAVE OS >maintained file pointers. I assume (correct me if I am wrong) that >APR_APPEND has the same semantic meaning as Unix O_APPEND. If that >assumption is correct, then passing in APR_XTHREAD|APR_FILE_APPEND on an >apr_file_open is not correct and should be flagged as an error at file open >time. My inclination is to make the check at file_open time rather than in >this code.
Nope. APR_XTHREAD files must be readable, writeable and totally compatible with APR_APPEND. It's a couple of extra LOC, please add them or post the final patch for me to massage. These files have APR maintained file pointers for compatibility with the API. APR_XTHREAD and APR_SENDFILE_ENABLE must remain semantically equivalent to a usual file. They simply might consume more overhead, or less, depending on what the application is. >Bill, passing in APR_FLOCK_SHARED fixed the problem. (hitting my forehead >and sounding like a Homer). You can't flock SHARED... that denies everyone (including yourself) write access to the file. Please review the FileLockEx docs.
