I have a program to control a speakerphone modem. One thread monitors for rings, based on xringd code, using an icotl TIOCMIWAIT. This uses one file descriptor number to the modem /dev and runs in the background. Other threads open of the modem for write access and send sequences to answer the call or dial a call, etc.Program is using qt4, written as a plasma applet.
Problem is that xringd thread never ends. Closing the plasmoid viewer or otherwize removing it leaves this thread running even after its QThread object has been destroyed. Not very well behaved at all. So after several sessions of testing, the modem is borked and nothing can access it, not even minicom. One can open the /dev but nothing more. Raising signals as set up in xringd has no effect. Only an outright kill of the whole thing MAY (no destroyed while running message anyway) stop it. NO answers to this on Google. The man pages for these calls show some possibilities that could be tried from the applet's destructor.: 1. Insert a character into the read buffer that generates the signal? There are a whole series of these, one for each signal. However, simply raising the signal did not work. 2. Do an ioctl to set the ring bit. Before this I could set an abort flag and end the run at this point? Note that this program uses two file numbers, one for the read-only xringd thread and one for any operations that need write access. If there were a way to turn write access on and off, one descriptor number would suffice. Keeping things read-only until I want to take action keeps the program from interfering with getty operations and such if the user uses them. Getty can answer the call if the user does not do so from the program after n rings, for example. That's how xringd does it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
