Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <20050719033840.6h8tv6vvms4gc0ko@paul.querna.org>
Date: Tue, 19 Jul 2005 03:38:40 -0500
From: chip@force-elite.com
To: Brian Pane <brianp@apache.org>
Cc: dev@apr.apache.org
Subject: Re: apr_pollset multithread semantics?
References: <1A8FA40C-CAD4-43D9-AB7E-D86F85D6776E@apache.org>
	<20050718124121.GB9166@redhat.com>
	<269CFDEE-BF7D-4317-BDDB-580D73C1CDF3@apache.org>
In-Reply-To: <269CFDEE-BF7D-4317-BDDB-580D73C1CDF3@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)

Quoting Brian Pane <brianp@apache.org>:

> On Jul 18, 2005, at 5:41 AM, Joe Orton wrote:
>
>> On Sun, Jul 17, 2005 at 07:20:10PM -0700, Brian Pane wrote:
>>
>>> For implementations of apr_pollset that support the
>>> APR_POLLSET_THREADSAFE option to apr_pollset_create(), what's  supposed
>>> to happen if thread T1 adds a descriptor to a pollset while thread T2
>>> is blocked in a call to apr_pollset_poll() for the same pollset?
>>>
>>
>> I had actually presumed it would be OK to leave the behaviour as not
>> explicitly defined, but I can see it would certainly be useful to be
>> able to rely on your (A) case below if that can actually be  guaranteed.
>
> Yes indeed, (A) or even (B) can be very useful when designing, say,
> httpd MPMs. :-)

Yes, as part of the design, I relied upon that fact that all of our supported
backend APIs use bahavoir (A).

I think we should add this behavoir to the documentation, explicitly.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.