Turning FNDELAY *off*
Barton E. Schaefer
schaefer at ogccse.ogc.edu
Sun Aug 13 05:21:52 AEST 1989
In article <4180 at ogccse.ogc.edu> I wrote:
} Surely there must be an obvious way to do this, and I'm just missing it.
}
} if (fcntl(sd, F_SETFL, FNDELAY) < 0) {
} perror("fcntl");
} exit(1);
} }
}
} Is there any way to restore blocking read/write on a descriptor?
As expected, I was indeed missing the obvious. The following people all
pointed it out in basically the same way, with various degrees of "Hint!
Hint!" :-) commentary leading up to the actual solution:
Chris Torek <chris at mimsy.umd.edu>
loverso at Xylogics.COM (John Robert LoVerso)
guy at auspex.com (Guy Harris)
The answer is that, as I should have realized, fcntl() works just like
ioctl(), and with F_SETFL it sets/clears whatever bits are on/off in the
third parameter. So for my particular problem, it suffices to do
if (fcntl(ad, F_SETFL, 0) < 0) {
perror("fcntl");
}
and, in the more general case,
if ((flags = fcntl(ad, F_GETFL, 0)) < 0) {
perror("fcntl: can't get flags:");
}
else if (fcntl(ad, F_SETFL, flags & ~FNDELAY) < 0) {
perror("fcntl: can't set flags:");
}
I got a different answer from Phil Hochstetler at Sequent, for you other
DYNIX users. I haven't tried this one, because the fcntl() solution
works fine.
} From: sequent!phil (Phil Hochstetler)
}
} I believe the proper way to do this is:
}
} int on = 1,
} off = 0;
}
} /* turn on non blocking I/O on a socket */
} if (ioctl(fd, FIONBIO, &on) < 0) {
} perror("ioctl");
} exit(1);
} }
}
} /* turn off non blocking I/O on a socket */
} if (ioctl(fd, FIONBIO, &off) < 0) {
} perror("ioctl");
} exit(1);
} }
}
} I think the problem is a basic BSD one .. 4.X BSD never did this
} the way the doc states (or used to do it both ways). Give the above
} a try.
} --
} Phil Hochstetler UUCP: uunet!sequent!phil
Thanks to everyone who responded.
--
Bart Schaefer "And if you believe that, you'll believe anything."
-- DangerMouse
CSNET / Internet schaefer at cse.ogc.edu
UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
More information about the Comp.unix.questions
mailing list