Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of rooneg@gmail.com designates
 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=HrVqPwJBrFIZA70F0CORVcwwE8YU6CfzOyYlzqNAfVh2v+eVSKDjc1rELKKGXscS5hwUvCkGYXiyPZN85Bot7jxcpdLM8s6ADB7x0kq3gfP9R+xYHF6xtL8zDEjZlKGONbWh0ATDFdfarrtTkCCwgdTihkY+soSmQ6VO1bwWFt0=
Message-ID: <7edfeeef0701141349n61ba7c88u4565f6a560dd65aa@mail.gmail.com>
Date: Sun, 14 Jan 2007 16:49:24 -0500
From: "Garrett Rooney" <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: "Lucian Adrian Grijincu" <lucian.grijincu@gmail.com>
Subject: Re: New Vista APIs
Cc: dev@apr.apache.org
In-Reply-To: <acf3f2e60701132047yd3c8a6xe72c1191ddb3f0c9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <acf3f2e60701060723y19a2bc6dk829fed9288ec3dce@mail.gmail.com>
	 <7edfeeef0701060820k717f9465nc775d249e00c408f@mail.gmail.com>
	 <acf3f2e60701132047yd3c8a6xe72c1191ddb3f0c9@mail.gmail.com>

On 1/13/07, Lucian Adrian Grijincu <lucian.grijincu@gmail.com> 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