HELP: DCD failure detection with polled reads (SCOV.3.2)

[Brandon S. Allbery KB8JRR]

As quoted from <4933 at acorn.co.uk> by dave at acorn.co.uk (David Lamkin):
+---------------
| I'm having trouble detecting carrier fail from my Hayes compatible
| modem on my SCO Unix V.3.2 release 2 system. The application is using
| serial lines as a background data transfer (so I can't make the
| serial line tty my controlling terminal) & I was hoping to avoid the
| need for a separate process by setting VMIN & VTIME to 0 and thus poll
| on my reads. Everything works fine but when the carrier drops reads
| just return "no bytes read".  Am I liable to be able to make this
| work? (All the example of code I can find use blocking reads...)
+---------------

read() returning 0 is the *only* way to detech dropped carrier.  Since this is
also the return value when there's no pending input, you're out of luck there.

HOWEVER, you can use blocking reads and do your polling in several other ways:

(1) rdchk(fd) returns 1 if there are characters available from fp *or fp is at
    EOF (i.e. carrier dropped)*.  (Xenix-compatible)  (man S rdchk)

(2) Use the select() system call.  Since this was copped from BSD, lots of
    BSD programs show you how to use this; but SCO UNIX doesn't use the
    "exception" vector, it overloads the "read" vector instead.  Works
    like rdchk(), but can check multiple file descriptors.  (man S select)
    (Sufficiently recent Xenix understands this)

(3) Use the (surprise!) poll() system call.  This is the Streams version of
    select, and has a somewhat simpler programmer interface (no silly bit
    vectors to play with).  Aside from the way it takes and returns values,
    it's pretty much the same as select (in fact, I wouldn't be surprised if
    all three are really the same system call with three different library
    function wrappers).  (Xenix only if you bought a TCP/IP package.)

VMIN=0, VTIME=0 was added to *some* System V's because System III programmers
had a tendency to ignore the manpage's statement that this did NOT do a poll,
then submitted bug reports when it didn't do a poll.  Sigh.  I suspect the
concept of packet drivers is beyond many programmers.  In any case, it's a
hack and nonportable (most non-Intel ports of System V will do blocking input
in this case) and should be avoided.

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery at NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY