Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates
 64.233.184.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=l5onB9jM+fU2yVM6egpLJqqonmHFJg9i89Ez8HjTUP4+6sJVszLjLvO5ht+NXeGBl7SertQYIbdFqfw32hC7Yn34wq6/Igbx23/FZwyWK5vRbmkoDXpNv5ESdaAdqmt/iXF9Ecsc5kUJUbiEQzQQaU0xv67WtJyFM/7DhemAvGQ=
Message-ID: <7edfeeef0601271401x21719831jf220586aef5dec82@mail.gmail.com>
Date: Fri, 27 Jan 2006 14:01:13 -0800
From: Garrett Rooney <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: APR Developer List <dev@apr.apache.org>
Subject: apr_pollset_poll test failures in 1.2.3 release
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It seems that back in r349169 brianp added a test to test/testpoll.c
that confirms that if you've got a file descriptor in a pollset that
is being polled on both readability and writability (i.e. reqevents =3D
APR_POLLIN | APR_POLLOUT) you get back a return value of 1 when you
try to poll it.  This is rooted in a fix to the select based
implementation where it formerly would return 2, but you'd only
actually get one result in the result_set array.

This is all well and good in select land, but it falls down hard on
systems that use either kqueue (i.e. FreeBSD and some versions of
Darwin IIRC) or (if I'm reading the code right) event ports (i.e.
recent versions of Solaris).  In these apr_pollset implementations
you'll get back two elements in your result set, both pointing to the
same underlying file descriptor but with different rtnevent settings.

The actual documentation of the pollset interface is unclear on what
the actual desired behavior in this case is.

Personally, I don't think this problem is enough to keep us from
releasing 1.2.x to the world, the kqueue backend (AFAICT) has always
worked this way, and the world hasn't ended yet.  They're slightly
inconsistent, which is unfortunate, but it's debatable if the test is
correct or not, given our historical behavior in this case.

Thoughts?

-garrett