| Title: | -={ H A C K E R S }=- |
| Notice: | Write locked - see NOTED::HACKERS |
| Moderator: | DIEHRD::MORRIS |
| Created: | Thu Feb 20 1986 |
| Last Modified: | Mon Aug 03 1992 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 680 |
| Total number of notes: | 5456 |
This is such a great conference, I thought I'd describe something
else that confuses me, and see what everyone says.
I'm working on two programs that talk through DECnet task-task links.
The code has been 'in-place' for a while, and seems to work fine.
One program runs a screen/keyboard interface utilizing SMG routines.
When the operator selects an action, a message is written over the
link. Also, data can arrive over the link unrelated to whatever
the operator is doing and can cause the screen to be updated at AST level.
Input is in two forms - SMG$READ_KEYSTROKE and SMG$READ_STRING.
(SMG is NOT the output utility.)
Following? Good.
OK, here's the juice. When the program is awaiting a keystroke via
SMG$READ_KEYSTROKE at main level, when a read AST completes on the
link, the ast routine updates the screen, and it is displayed
immediately. Just what I like.
However, if SMG$READ_STRING is expecting input at the time, arriving
data may or may not be displayed immediately. When the operator has not
begun typing, it still works ok. However, once he begins typing
a string, if any asynchronous information comes over the line, the
results ARE NOT DISPLAYED until he completes his input and presses
RETURN. Then, everything catches up. (At this time, I don't know
if link io AST's are held during SMG$READ_STRING or if it's just that
screen io is delayed. I don't know how to tell, either.)
I am debating whether or not to write my own READ_STRING routine
that uses SMG$READ_KEYSTROKE, and assembles the input one key at
a time into a buffer.
Do I have to?
Why does this happen?
Kevin Mendel
P.S. I hope this made sense.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 642.1 | Nature of the beast, I'm afraid | MDVAX3::COAR | My hero? Vax Headroom, of course! | Tue Dec 29 1987 14:06 | 22 |
> (At this time, I don't know
> if link io AST's are held during SMG$READ_STRING or if it's just that
> screen io is delayed. I don't know how to tell, either.)
The screen I/O is being delayed. I can't give you a good reason
why, other than `that's just the way things be!' I suspect it has
to do with the way the TTDRIVER is coded; once the first input
character interrupt is received, all activity is blocked until the
read completes (i.e., TTDRIVER receives something it thinks is a
terminator, or the buffer is filled, or the timeout expires). I
think your best bet is to use SMG$READ_KEYSTROKE and assemble the
characters yourself. Sorry.
#ken :-)}
P.S.: As far as read-with-timeout goes, does the timeout get
restarted after each character read? So, if you're
reading 2 characters with a 10-second timeout, and you
wait 5 seconds before typing the first, do you now have
10 seconds in which to type the second? Or will it
wait forever? I suspect the former, but I'm too lazy
to investigate right now.. ;-)
| |||||
| 642.2 | SMAUG::MENDEL | Pessimists Always Get Good News. | Tue Dec 29 1987 15:58 | 13 | |
> I
> think your best bet is to use SMG$READ_KEYSTROKE and assemble the
> characters yourself. Sorry.
Wasn't your fault. Besides, I'll forgive you, because I suspected
as much, and the routine is already written. Works _slightly_ slower
than normal, but that's life. It was fun getting CTRL-E, CTRL-H,
etc. to work. Insightful, even.
Thanks much.
Kevin
| |||||
| 642.3 | VIDEO::LEICHTERJ | Jerry Leichter | Tue Jan 05 1988 00:35 | 14 | |
This is indeed a basic property of the terminal driver; it is fully discussed in the I/O User's Guide section on the driver. Terminal I/O is not quite full duplex: Writes will normally wait for any reads that have already "started" to complete. The "breakthrough write" modifier exists exactly to allow you to get around this behavior; unlike a normal write, a breakthrough write WILL break through any currently-active READ. (Don't confuse breakthrough writes with the $BRKTHRU call. This implements broadcasts by doing breakthrough writes to multiple terminals; but you can do any I/O you like with the breakthrough modifier. Just be sure you read the stuff in the I/O User's Guide carefully!) (In particular, note that a breakthrough write that gets queued behind a non- breakthrough write will wait for the first write to complete.) -- Jerry | |||||