and@ux.rfhsm.lon.ac.uk (Andy Holyer) (08/31/90)
>>>>> On 29 Aug 90 15:44:50 GMT, Leslie Mikesell <les@chinet.chi.il.us> said: les> .... The real problem is when you have les> placed a long distance call to or from a modem on a unix machine and les> pick up a ^S from line noise. I've even seen cases where the device les> driver would lock up so that even a kill -9 wouldn't release the les> process and there was no way to drop the call without physical access to les> the modem. I've seen this problem quite frequently using terminals with XON/XOFF handshaking - I find that few sites are willing to pay for more than 4-wire cabling IMH experience. A notable offender seems to be GNU's bash shell. On occasions the only way to unhang a line is to reboot (sometimes, I've even known a *power*down* to be necessary :-( ) Is there a less drastic solution? ------------------------------------------------------------------------------ | && | | | & & | &ndy Holyer | | & & | Snail: Dept. of Medical Informatics & Computing, | | && | Royal Free Hospital School of Medicine, | | & & & | Rowland Hill St. | | & & & | London NW3 2PF | | & & | England | | & & & | JANET: and@uk.ac.lon.rfhsm.ux | | & & & | Voice: (+44) 1 794 8673 | | &&& & | | |----------------+-----------------------------------------------------------| | "It's not easy having a good time. Even smiling makes my mouth hurt" | | Frank N. Furter | ------------------------------------------------------------------------------
guy@auspex.auspex.com (Guy Harris) (09/02/90)
>Most printers will supply a ^Q when powered up, when the lid is closed, >when the on-line button is pressed, etc. I'd prefer for the computer >to wait for such an occurrance rather than trying to guess when the >paper supply has been replenished. I'd prefer that too; I was bit by the S3 tty driver's insistance on turning off flow control and sending any buffered-up data when the tty line was closed. I'm just asking how a session manager would help in the case where a ^Q sent by the printer in the circumstances you list gets lost in transit. >The real problem is when you have placed a long distance call to or from >a modem on a unix machine and pick up a ^S from line noise. I've even >seen cases where the device driver would lock up so that even a kill -9 >wouldn't release the process and there was no way to drop the call without >physical access to the modem. If the call is still active, presumably typing ^Q would unlock the line, unless there's a driver bug. Hanging the phone up should unlock the line too, unless there's a driver bug....
guy@auspex.auspex.com (Guy Harris) (09/02/90)
>Is this meant to imply that the developers of STREAMS don't understand >unix? Given that the S5R4 pty driver, at least, returns 0 on the master side when the slave side is closed, and that it's the *BSD* pseudo-tty driver that behaves in the fashion Doug is complaining about, I don't think that's what he meant to imply... >A read on a STREAMS file is documented to return -1 when O_NDELAY >is set and there is no data available ...and since that's not a case of a "normal EOF", it's not what you should be inferring, either. >(which has unfortunately been propagated into the tty emulation of at >least some network implimentations). Prior to S5R3.2 or so, there was no way for a streams device to indicate that O_NDELAY should behave in the old tty driver fashion. We (Sun) added a mechanism (basically S5R3.2-compatible) to the SunOS 4.0 streams code which was S5R3.1-based, because we knew this was a compatibility problem; apparently, the implementors of said tty emulations weren't as aware of this as we were. One hopes the S5R3.2-based versions of those tty emulations are polite enough to request old-style behavior from the stream head....
bill@bilver.UUCP (Bill Vermillion) (09/02/90)
In article <3998@auspex.auspex.com-> guy@auspex.auspex.com (Guy Harris) writes:
->>The real problem is when you have placed a long distance call to or from
->>a modem on a unix machine and pick up a ^S from line noise. I've even
->>seen cases where the device driver would lock up so that even a kill -9
->>wouldn't release the process and there was no way to drop the call without
->>physical access to the modem.
->If the call is still active, presumably typing ^Q would unlock the line,
->unless there's a driver bug. Hanging the phone up should unlock the
->line too, unless there's a driver bug....
Not if the control S was sent from the host to the terminal. The host has
to send the control Q at that time. Good communications programs have an
over-ride, but I have seen many that don't, and you are out of luck.
--
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
: bill@bilver.UUCPpcg@cs.aber.ac.uk (Piercarlo Grandi) (09/04/90)
On 29 Aug 90 15:33:06 GMT, les@chinet.chi.il.us (Leslie Mikesell) said: les> In article <13650@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) les> writes: gwyn> In article <6038@muffin.cme.nist.gov> libes@cme.nist.gov (Don gwyn> Libes) writes: libes> Why do pty's return EIO instead of 0 upon EOF? gwyn> If they do this, it is clearly wrong and would most likely be due to gwyn> UNIX development now being done, or at least directed, by people who gwyn> don't understand UNIX. read() should not return -1 upon encountering gwyn> normal EOF on ANY object. les> Is this meant to imply that the developers of STREAMS don't understand les> unix? As I understand it, several people have a grudge against USG/USO for taking the research streams and hacking them (mostly disagreeably). les> A read on a STREAMS file is documented to return -1 when O_NDELAY les> is set and there is no data available (which has unfortunately been les> propagated into the tty emulation of at least some network les> implimentations). Apparently there is some reason to want to know les> about zero length messages. Yes, *if you do messages*. Unfortunately all of UNIX is based, right or wrong, on the idea that the fundamental abstraction is a byte stream, not a message/record stream. The UNIX philosophy is that if you want boundaries you use an higher level protocol (prefix each messages/record by its length, out-of-band record boundaries, whatever). I actually prefer discrete packets (that can be typed) to virtual circuits (which are untyped byte streams) as fundamental IPC abstraction, but after all you can always build one from the other. Reread how Rochking ("Advanced Unix programming") discusses the various IPC possibilities under various Unixes, concludes that named pipes are the right thing, and then proceeds to implement records/messages on top of named pipes. Originally streams were essentially named pipes with dynamically selectable line disciplines. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
les@chinet.chi.il.us (Leslie Mikesell) (09/04/90)
In article <3999@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Prior to S5R3.2 or so, there was no way for a streams device to indicate >that O_NDELAY should behave in the old tty driver fashion. We (Sun) added a >mechanism (basically S5R3.2-compatible) to the SunOS 4.0 streams code >which was S5R3.1-based, because we knew this was a compatibility >problem; apparently, the implementors of said tty emulations weren't as >aware of this as we were. One hopes the S5R3.2-based versions of those >tty emulations are polite enough to request old-style behavior from the >stream head.... Nope, the 3B2 SysVr3.2 still returns -1 on starlan tty emulation when O_NDELAY is set and there is no data to read(). (Anyone wondering why GNU Emacs or rn don't work right?). And setting VMIN and VTIME to 0 doesn't prevent read() from blocking, either. Oddly, the 386 version of SysVr3.2 handles both correctly. Les Mikesell les@chinet.chi.il.us
jbm@celebr.uucp (John B. Milton) (09/04/90)
In article <24356@adm.BRL.MIL> and@ux.rfhsm.lon.ac.uk (Andy Holyer) writes: >>>>>> On 29 Aug 90 15:44:50 GMT, Leslie Mikesell <les@chinet.chi.il.us> said: >les> .... The real problem is when you have >les> placed a long distance call to or from a modem on a unix machine and >les> pick up a ^S from line noise. I've even seen cases where the device >les> driver would lock up so that even a kill -9 wouldn't release the >les> process and there was no way to drop the call without physical access to >les> the modem. > >I've seen this problem quite frequently using terminals with XON/XOFF >handshaking - I find that few sites are willing to pay for more than >4-wire cabling IMH experience. A notable offender seems to be GNU's >bash shell. On occasions the only way to unhang a line is to reboot >(sometimes, I've even known a *power*down* to be necessary :-( ) >Is there a less drastic solution? >... Yes. I have a program I call "clocal" that is a tool for messing about with ports. It has tons of error messages and signal handling, but it boils down to this: #include <fcntl.h> #include <termio.h> f=open(line,O_RDONLY|O_NDELAY); /* always succeeds */ ioctl(f,TCXONC,1); /* restart the UNIX side */ ioctl(f,TCXONC,3); /* send a ^Q to the terminal */ On some SYSVs the driver does not handle NDELAY properly and the port will become a tar baby. Any process that opens the port is stuck to it until reboot. Some drivers will hang in the first ioctl. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
guy@auspex.auspex.com (Guy Harris) (09/11/90)
>Not if the control S was sent from the host to the terminal.
Uhh, we weren't *talking* about ^S's sent from the host to the terminal.
We were talking about ^S's sent from the terminal to the host, because
we were talking about *hosts* getting hung up when trying to close a
serial port because the serial port is ^S'ed and output never drains.