From: Lois Goldthwaite (loisg_at_[hidden])
Date: 2001-03-06 06:56:48
Not argument about the utility -- on the rare occasions when it's
absolutely needed -- but is this really something a language can
standardize? Isn't it dependent on a BIOS (or lower-level) facility that
the operating system might not expose? As Beman pointed out,
non-buffered I/O can hit performance, so O/S designers might come down
for the other side of the trade-off. Many Unix platforms provide
ioctl(), which is either Posix or Single Unix Specification or both.
In many cases, the main use of kbhit() on PCs used to be so that you
could ask the user to "hit any key to continue" -- whereas on Unix you
had to "hit any key followed by the return key." As GUI interfaces have
become popular, even this usage is dying out. And on PCs, IIRC, pipes
are, or used to be, imitated using ordinary files to transfer data to
the receiving program sequentially, which lessens the utility of
non-blocking I/O. Which is not to say I couldn't see uses for it, but I
do think it's basically something that has to be standardised at the O/S
> Message: 21
> Date: Tue, 06 Mar 2001 08:54:02 -0000
> From: pinkfloydhomer_at_[hidden]
> Subject: Re: Non-blocking I/O
> Thanks, but it wouldn't solve my problem.
> First of all, I want this to work on many different platforms, not
> only Win32 and Linux.
> Secondly, I want to be device independant in the sense that I don't
> care if the stdin is tied to a keyboard or a pipe. It has to work with
> a pipe as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk