Chris Breemer wrote:
>
> Cas Caswell wrote:
>
> [snip]
> > If you run remsh and do not specify the -n option to disable STDIN, remsh
> > forks a child process to read STDIN. So you now have two processes active
> > and doing I/O to your terminal. It is my understanding that in Unix, you
> > can have a read on STDIN and do a write to STDOUT and have the write
> > go through. With MPE, once you get to the terminal driver, ie once the
> > file sys maps STDIN and STDOUT to the physical device to talk to, the
> > driver is written such that you do not write through a read. When the
> > read completes, then the write is sent to the physical device. So in MPE
> > land if the child process hangs a read on STDIN, it will block writes
> > from the parent prcess to STDOUT.(ignoring pre-emptive writes)
> >
> We had the same problem in our application. A child process was doing the
> keyboard read and sending the keystrokes over a pipe to the parent. The
> parent wanted to update the screen and could not do it until the child
> received at least one character. We got around this problem by using an
> XL supplied by CSY in Boeblingen,
> which could do screen writes on sub-MPE level so that it would not have
> to wait for a blocking keyboard read. This worked well enough, but only
> over a hardwired or DTC terminal. It failed over a network connection.
>
> I would have hoped that with the POSIX implemetation the keyboard and
> screen would not lock each other out, but aparently this is still the case.
> I suppose in a 'real' UN*X there are actually two device drivers, one for
> screen and one for keyboard, whereas in MPE there's only one, for the thing
> MPE calls 'terminal'. I don't think POSIX specifies anything on this level.
> However it seems likely that other posix apps being ported in from UNIX
> will hit this same problem. Is it likely to get changed in the future ?
> Are there any hard reasons for having this blocking scheme (except for
> historical MPE design features that might not apply to posix ) ?
>
Chris and Cas should consider themselves lucky if they've gotten all the way
to 1997 before discovering what I probably first saw in 1977. Now, did you
guys spend your money wisely on Jeff Vances "Lets clean up Posix" list? You
should have spent your bucks on getting select to work on terminal files.
There are lots of differences between MPE and Unix terminal i/o, but the
one significant difference is Nowait I/O for MPE and select for Unix.
Suppose you want to read data from a terminal(keyboard) and write it to a
message file. Simultaneously, you want to read from another message file
and write it to the terminal(screen).
In MPE you would code up something like the following. (Many details
omitted.)
open(inmsgfile)
open(terminal)
termreadposted = false
open(outmsgfile)
outmsgfilereadposted = false
while something to do
if !termreadposted
then read(terminal), termreadposted = true
if !outmsgfilereadposted
then read(outmsgfile), outmsgfilereadposted = true
fnum = iowait
if fnum == terminal
write(inmsgfile), termreadposted = false
else if fnum == outmsgfile
abortread(terminal), termreadposted = false,
write(terminal), outmsgfilereadposted = false
end
if outmsgfilereadposted
abortread(outmsgfile)
close(outmsgfile)
if termreadposted
abortread(terminal)
close(terminal)
close(inmsgfile)
The key point is that the reads are issued and then you wait for one of
them to complete. When the outmsgfile read completes, you have to abort
the terminal read in order to do the write.
In Unix you would code up something like the following. (Many details
omitted.)
open(inmsgfile)
open(terminal)
open(outmsgfile)
while something to do
fnumlist = select
if terminal in fnumlist
read(terminal), write(inmsgfile)
if outmsgfile in fnumlist
read(outmsgfile), write(terminal)
end
close(outmsgfile)
close(terminal)
close(inmsgfile)
The key point is that the reads are not issued until the select says that
the read would complete(under some condition.) This would work fine on MPE
as the terminal read and write are not overlapped. But, select doesn't
work for terminals, so you're stuck. Any Unix/Posix program that has this
model in it will be hard to port.
--------------------------------------------------------------------
Ross Scroggs email: [log in to unmask]
Telamon, Inc. CIS: 76011,2234
492 Ninth Street, Suite 310 voice: 510-987-7700
Oakland, CA 94607-4098 fax: 510-987-7009
--------------------------------------------------------------------
|