The Slim Reader/Writer (SRW) Locks implemented in Vista are blocking-only.
Because of this, i don't think there's a way we can implement apr_thread_rwlock_tryrdlock through SRWLocks.
A possible solution that I see means defining:
A user that does not need the non blocking apr_...try functions will create the rwlock by specifying this flag.
- a new constructor function:
- apr_thread_rwlock_create2 (apr_thread_rwlock_t **rwlock, apr_pool_t * pool, apr_int32_t flags )
- a special APR_RWLOCK_FAST_BLOCKING flag.
and apr_...try functions shall return some speciffic error.
If sometimes later he decides that he may want apr_thread_rwlock_tryrdlock he can just remove the APR_RWLOCK_FAST_BLOCKING flag.
only on vista and laters, if SRW locks have been enabled(aka #define APR_HAVE_SWR_LOCKS 1) this will have an overhead though:
- apr_thread_rwlock_t will need a new member to hold this flag
- every function call shall have to check if the flag is set or not, to switch between implementations.
Another solution would mean creating a special blocking apr_thread_blrwlock_t structure and the same set of methods expect the two apr_...try ones. This does not have the overhead of the former solution, but, if a developer might discover during development time he *must* use one of the apr_...try functions he'll have a bit more work: search and replace "apr_thread_blrwlock*" with "apr_thread_rwlock*".
Oh yeah, and we can just drop this functionality altogether and keep the current win32 on all platforms:)
On 1/7/07, E Holyat <email@example.com
> I took a class with the author of the Read/Writer API (Jeffrey Richter). It
> was written using the InterlockedExchange API. It would be a huge
> improvement implementing the new API.
Lucian Adrian Grijincu