ac@utgpu.UUCP (04/30/87)
1/ I have had some success with the "select" function. In particular, I have actually seen the BASIC09 example for "select" work. The only difference from my earlier experiments that failed is that this time I did away with /term and ran the experiment from /w1. It seems that "select" cannot work properly when /term is involved. In my case I EX'ed the shell in /term and then deiniz'ed it from /w1. I'm not sure these steps were neccessary but in my case I don't have enough memory to proceed without doing this. To all who might have had this problem can you confirm that /term was involved in your case as well. 2/ It has been mentioned that output can't be sent to a window with a shell running in it. Effectively this is true but someone claimed that it was neccessary to use the clear key to select the window and then get the shell to do a little output to allow the other output (sent from some other window) to arrive. Strictly speaking the problem here is input, NOT output. After the shell writes the OS9 prompt is issues a read (readln I think). This percolates down to the device driver who knowing their is no input available puts the user to sleep (after arranging that the IRQ routine will wake it up when input is available). Now you go over to some other window and try to sending something to the window with the shell. IOMAN (I believe) notices the path is in use and suspends the sender. He also arranges that the sender be woken up when the outstanding read is cleared. This queueing is performed with the IOQ service. When you select the shell window with the clear key and hit enter you satisfy the read. Sometimes it is neccessary to hit return several times because the shell may re-enter the read before the message sender gets dispatched. Running almost any old command from the shell window will generally allow enough time for the message to arrive. 3/ Just wondering, anybody know why INIZ is INIZ and not INIT or something like that? 4/ Point 2 above reminds me of another problem which confuses many. Terminal programs often have an outstanding read to their modem. When you go to terminate the program it may hang. Deskmate certainly has this problem. Most people just give up and hit the reset button. I put 2 and 2 together one day and when Deskmate next hung I tried bopping the acoustic coupler to generate a garbage character. Sure enough, Deskmate sprung back to life, terminated the Telecom function and returned to the main menu. The problem here is that most device drivers do not honour any signals except the wakeup signal from the IRQ routine. Smarter drivers do check for kill signals. I'm not sure if that entirely fixes the problem either. -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet
durham_2@husc4.HARVARD.EDU (peter durham) (05/01/87)
In article <1987Apr30.125815.16660@gpu.utcs.toronto.edu> ac@gpu.utcs.toronto.edu (Mark Acfield) writes: >3/ Just wondering, anybody know why INIZ is INIZ and not INIT or something >like that? This is because there is already a module called Init in the OS-9 system... it contains a table of information used when starting up. Thus it is not possible to have a command "Init" because the two module names would conflict. Iniz means init but the z makes it different. Actually, considering the internal name of the systems calls they use, "Iniz" and "Deiniz" should probably be "Attach" and "Detach". -- Peter Durham UNIX: durham_2@husc4.harvard.edu COMPUSERVE: 73177,1215 seismo!harvard!husc4!durham_2 DELPHI: PEDXING ______ / / / / Tandy / / / / Color Computer 3 and Microware's OS-9 Level II /_/_/_/