home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / sys5 / r4 / 947 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.1 KB
  1. Xref: sparky comp.unix.sys5.r4:947 comp.unix.sys5.r3:151
  2. Path: sparky!uunet!ogicse!news.u.washington.edu!uw-beaver!micro-heart-of-gold.mit.edu!eddie.mit.edu!minya!jcsu
  3. From: jcsu@minya.UUCP (John Chambers)
  4. Newsgroups: comp.unix.sys5.r4,comp.unix.sys5.r3
  5. Subject: Can Sys/V force DTR low or high?
  6. Keywords: DTR
  7. Message-ID: <1406@minya.UUCP>
  8. Date: 22 Dec 92 22:43:34 GMT
  9. Article-I.D.: minya.1406
  10. Followup-To: poster
  11. Lines: 32
  12.  
  13. The subject is probably self-explanatory. On BSD-like systems, you can
  14. make a call of:
  15.    ioctl(dev,TIOCCDTR,0L);
  16. and  DTR  will  instantly  drop, telling a (sane ;-) modem to hang up.
  17. I've poked around in TFM for several Sys/V releases (both R3 and  R4),
  18. and as near as I can tell, there is no (documented) equivalent of this
  19. operation in Sys/V.
  20.  
  21. The manuals do say vaguely (without mentioning DTR) that the line will
  22. be closed when the last program closes the port, if HUPCL is set.  But
  23. that isn't even close to what is needed. To use that, my program would
  24. have  to first find out what processes have the port open, and this is
  25. known to be a very difficult problem in general.  Then, if this  could
  26. even  be  determined,  my  program  would have to kill all the others,
  27. which means that I'd have to  be  running  as  root,  which  is  quite
  28. unacceptable.
  29.  
  30. In any case, even if doable by this method, it  can  potentially  take
  31. many  seconds  (or  minutes)  to  grovel  around in the kernel for the
  32. information, and when you want to hang up on a caller, you want to  do
  33. it  NOW,  not  some  time in the indefinite future that depends on the
  34. size and complexity of the kernel's process table.
  35.  
  36. Another reason not to do it in such a byzantine fashion is that for my
  37. program  to  close  the  port would leave a short window when it isn't
  38. open, leaving  it  up  for  grabs  by  other  programs.   That's  also
  39. unacceptable for the application, which is supposed to own the port.
  40.  
  41. So is it possible for a Sys/V process that has a port open to forcibly
  42. drop DTR? (If not, I have yet another entry in my list of reasons that
  43. we should list variants of Sys/V as unacceptable for the project.  ;-)
  44. Might it be documented anywhere?
  45.