On Thu, Nov 09, 2006 at 06:18:17PM +0100, Mladen Turk wrote: > Joe Orton wrote: > > > >2) it's a really bad implementation. You can do the same thing portably > >by doing a poll() and a recv(,MSG_PEEK) AFAICT. There is no need to > >muck about with ioctls, and it can be done already without adding > >anything to APR. > > recv(, MSG_PEEK) is not portable
It's certainly *more* portable; it should work on any POSIX system unlike the ioctl. Have you tested it on Win32? With APR you'd have to use apr_socket_recvfrom to be able to pass a flags argument, annoyingly. >, so its not APR only anyhow. > Further more the poll resolution is millisecond. A zero-timeout poll or select is sufficient to determine readability without blocking. Actually if you use a non-blocking socket the poll/select should be unnecessary if using recv/MSG_PEEK anyway, it doesn't tell you anything extra. recv/MSG_PEEK == 0 => EOF => not ESTABLISHED recv/MSG_PEEK < 0 && !EWOULDBLOCKy(rv) => socket error, not ESTABLISHED recv/MSG_PEEK < 0 && EWOULDBLOCKy(rv) => empty recv buffer, ESTABLISHED > >2. b) using select() like that will SIGSEGV on Unix for an fd > > >FD_SETSIZE. There is no excuse to at least not use apr_poll() > > Hmm. select(1, ...) can probably be used instead select((int)sock + 1, ...) It's the FD_SET call which has undefined behaviour for an fd >= FD_SETSIZE. Calling select(1, ... on Unix will make select act like sleep() unless you have an fd == 0 entry in the fdset. Regards, joe
