>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