Joe Orton wrote: > > > 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. >
I can't think of a Unix tcp/ip stack that doesn't support MSG_PEEK. Even old vintage A/UX does :) We would also need to fudge a from for APR's recvfrom... (we should really be more regular recv()-like and allow from to be NULL and avoid having to return anything) > >, 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. > Plus select(1, ...) means that the fd must be 0 ;) -- =========================================================================== Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
