Apparently we've completely neglected the mutex locking around the public apr_file_flush API. From an external perspective, if a mutex exists, it must be used. From an internal perspective, we invoke flush from within an already-mutexed block of code (lock, flush, operation, unlock) so we absolutely don't want to mutex it.
I'm thinking of an apr_file_internal_flush API for the existing non-mutexed flavor, and make the public apr_file_flush API obtain the mutex where it's appropriate, and invoke apr_file_internal_flush inside the mutex code. Thoughts? Bill
