dave@acorn.co.uk (David Lamkin) (02/01/91)
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...) David Lamkin dlamkin@acorn.co.uk
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/07/91)
As quoted from <4933@acorn.co.uk> by dave@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@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