Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.217.21 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=qIlk3DyxbYGdyjSxfoseG54IMeTCmwmpzbcdAB4izXzcTQ28dSe65K22aHEE22xJ/y
         p1eHcvy+vztZ0mom/sYb9TbcMVzxf5HsczyYKh8U9nfd0fTLAX2RTwSsfkWacdI1/Wvr
         gRKxngc9YFtmfpjjaJT19cp77EYoOU0+ixFnk=
MIME-Version: 1.0
In-Reply-To: <498FF67B.3030900@apache.org>
References: <498FF67B.3030900@apache.org>
Date: Mon, 9 Feb 2009 06:42:56 -0500
Message-ID: <cc67648e0902090342p3ca38a8em3fc08c08e57a36d3@mail.gmail.com>
Subject: Re: [WIN32] Using WSAPool for Vista+
From: Jeff Trawick <trawick@gmail.com>
To: APR Developer List <dev@apr.apache.org>
Content-Type: multipart/alternative; boundary=000e0cd4050431b56f04627adfdb

--000e0cd4050431b56f04627adfdb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Feb 9, 2009 at 4:25 AM, Mladen Turk <mturk@apache.org> wrote:

> That makes me think we can have that generic, allowing
> different pollset providers for non-windows platforms
> as well (If it makes sense of course), eg. something
> like we have for proc_mutex.
> (apr_proc_mutex_unix_lock_methods_t would actually become
>  apr_poll_methods_t allowing choosing different
>  poll providers, again where it makes sense)


I thought (worried) that this might be desired at one point, but I think it
is only useful to work around bugs in our implementation or the associated
system feature.  (Up go the hands of the several people trying to use ab on
Leopard ;)  Have kqueue/epoll/etc. problematic in general?)

I believe it is as simple as:

select() vs. poll() is a no-brainer (*never* use the former if you have the
latter)
poll() vs. kqueue/epoll/etc. for apr_pollset_foo() is similar

Mutex methods on the other hand generally have interesting tradeoffs on
Unix, and the choice isn't clear.

--000e0cd4050431b56f04627adfdb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 9, 2009 at 4:25 AM, Mladen Turk <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:mturk@apache.org">mturk@apache.org</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That makes me think we can have that generic, allowing<br>
different pollset providers for non-windows platforms<br>
as well (If it makes sense of course), eg. something<br>
like we have for proc_mutex.<br>
(apr_proc_mutex_unix_lock_methods_t would actually become<br>
&nbsp;apr_poll_methods_t allowing choosing different<br>
&nbsp;poll providers, again where it makes sense)</blockquote><div><br></di=
v><div>I thought (worried) that this might be desired at one point, but I t=
hink it is only useful to work around bugs in our implementation or the ass=
ociated system feature. &nbsp;(Up go the hands of the several people trying=
 to use ab on Leopard ;) &nbsp;Have kqueue/epoll/etc. problematic in genera=
l?)</div>
<div><br></div><div>I believe it is as simple as:</div><div><br></div><div>=
select() vs. poll() is a no-brainer (*never* use the former if you have the=
 latter)</div><div>poll() vs. kqueue/epoll/etc. for apr_pollset_foo() is si=
milar</div>
<div><br></div><div>Mutex methods on the other hand generally have interest=
ing tradeoffs on Unix, and the choice isn&#39;t clear.<br></div><div><br></=
div></div>

--000e0cd4050431b56f04627adfdb--