Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
From: "James Mansion" <james@wgold.demon.co.uk>
To: "Greg Stein" <gstein@lyra.org>
Cc: <dev@apr.apache.org>
Subject: RE: io abstractions
Date: Sat, 1 Jul 2006 09:10:47 +0100
Message-ID: <HCEPKPMCAJLDGJIBCLGHIECCFKAA.james@wgold.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <6cca3db30606270312vf38e848vfd784fa802a70d38@mail.gmail.com>
Importance: Normal

>have synchronous APIs. Period. Yes, it would also be nice to have
>async, but that is orthogonal to the problem at hand.

Really?  What's all the APR_SO_NONBLOCK and apr_poll stuff for then?

APR_DECLARE(apr_status_t) apr_socket_send(apr_socket_t *sock, const char
*buf,
                                          apr_size_t *len);
...
 * This functions acts like a blocking write by default.  To change
 * this behavior, use apr_socket_timeout_set() or the APR_SO_NONBLOCK
 * socket option.
 * The number of bytes actually sent is stored in argument 3.

That does not seem to me to jive with 'synchronous APIS. Period.'

File IO might be synchronous., but then this is effectively an
admission that the 'unification' leaves a lot to be desired even
on platforms where a file descriptor 'looks like' a network or
pipe descriptor and can be included in select(), because the
behaviour is not the same.  To be sure, using select with files is
not so useful, but surely we've moved on in scalable server design
from that.

I have to say I fundamentally disagree with all these decorated
names anyway - why can't these objects essentially just have a
vtable pointer and indirect through that for operations?

The 'performance impact' will not be measurable next to the kernel
entry and IO operation.

But then I think that select/poll is the wrong abstraction anyway,
so what do I know. ;-)

James