jmg@cernvax.cern.ch (john gerard) (02/05/90)
The story so far: I run a 3270 emulation on behalf of users sitting on terminals on DECservers. These users can move to different sessions, so that output then gets hung up. However, I do not want the emulation to hang on output calls (fwrite, fputs, fputc or whatever), since the IBM may at any time send messages. I think I understand the normal idea behind a tty character device, though LAT is clearly a bit special. Now read on: I can clearly channel all output through my own routine(s), rather than through fwrite, fputs or whatever. However, my observation is that the select routine is not good enough for me because it may tell me that output can be done and yet the actual output may cause the program to be hung because it goes over the high water mark. Note that this applies to block or line buffered output: if I use unblocked output then select can work, but the overhead of unblocked output is too high for this to be a practical solution. Thus, how to know when the next output, even of a single character, would cause a blocking because of going over the high water mark? How, also, to know when output can again be accepted? Simple question, but no-one here seems to have an answer. It might depend on the way that output to a LAT device is handled: I know that the DECServer periodically asks for output and (maybe) gets a number of characters depending (I think) on the line speed of the terminal. However, what buffering, if any, is done for creating these LAT output packets is an unknown factor. Certainly, the code for creating these packets is hidden from me. One observation that I have is that a signal interrupt may cause some of these LAT output packets to get lost. I know that when I was testing using ITIMER_PROF and ITIMER_REAL I sometimes lost three or four of these packets. The DECserver kept asking at 70ms intervals for output, but suddenly some LAT output packets were completely skipped. Of course, the setitimer manual says that the routine handling the timer should be prepared to restart interrupted system calls, but what this means in the case of LAT output is hard to understand. Another funny about LAT! I have two DECstations offering the same LAT service: one for about 10 users, one for over 100 users. The 10-user one gets completely filled before the 100-user one gets any user. I thought that the LAT protocol had some better algorithm than that! Ultrix gurus, over to you!