On 1/13/07, Lucian Adrian Grijincu <[EMAIL PROTECTED]> wrote:
the two cond_wait functions in APR: apr_thread_cond_wait(apr_thread_cond_t *cond, apr_thread_mutex_t *mutex) and apr_thread_cond_timedwait (apr_thread_cond_t *cond, apr_thread_mutex_t *mutex, apr_interval_time_t timeout)use a apr_thread_mutex_t as the object being unlocked. the new condition variable form Vista unlocks either a CriticalSection or a SRWLock object (SleepConditionVariableCS and SleepConditionVariableSRW) the win32 implementation for apr_thread_mutex_t on Vista uses either Events or CriticalSections depending on weather APR_THREAD_MUTEX_UNNESTED was specified when the lock was constructed or not. We can't just use the new calls on Vista because we can't atomically "release" an event and sleep on the condition variable. Because of this we'll need a new constructor apr_thread_cond_create2 (apr_thread_cond_t **cond, apr_int32_t * flag, apr_pool_t * pool) and have the developer specify which kind of lock he's going to use with this lock. If he chooses to use APR_THREAD_MUTEX_UNNESTED locks, we'll revert to the current implementation. If he guarantees he won't use these kind of locks we can freely use the new Condition variables. anyways, my former question stands: how would you like apr to deal with this issue: have a secondary constructor, or have a new set of objects (or just forget about it)?
In general, it seems like if we can't provide a cross-platform API with this new low level interface, I don't see the point in using it at all... If it's absolutely going to require new interfaces with special cases to make it work, then I'm not sure what the real benefit would be. I mean this is a "Portable Runtime", after all. -garrett
