Re: term & user space console

[Marcus Brinkmann]

On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> I think this is a very good strategy.  Mach RPCs can be split into
> asynchronous IPC calls, but this is not true of most RPC systems that
> we might want to port to.  So it's ok to take advantage of the Mach
> semantics in Mach-specific code (like devio.c).  But in generic code
> (like your hurdio.c) we should avoid Machisms where possible.

Ah, yes, that makes sense.

> The Right Thing is surely two separate threads.  I'm not sure that
> select is really necessary at all however.  

I first had the idea to use one thread, and a single select with
SELECT_READING | SELECT_WRITING, and when I switched to the two
thread model I stuck with select.  But now that I think about it again
without select, I don't see a problem not using it.

> The reader thread does:
> 
>   while (1)
>     read data  -- blocking
>     hand returned data to middle layer
>     if (CREAD is turned off)
>       block until CREAD is turned on

I had the following in mind (version without select):

while (1)
  read data -- blocking
  if (CREAD is turned on)
    hand returned data to middle layer
  
The obvious difference is what happens to data that is available in the
underlying file while CREAD is turned off.  Both, devio and ptyio discard
such data, while in your design it would be delayed until CREAD is enabled.
I couldn't find out what is the right thing (the standards just say "enable
receiver" about CREAD).

> The writer thread is similar:
> 
>   while (1)
>     if (data remains to be written)
>       write data -- blocking (sometimes, not often)
>     block until data needs to be written

Well, I had this (non-select form):

while (1)
  while (output suspended or queue empty)
    block until output resumed and queue non-empty
  write data -- blocking

so basically the same, just taking output stopped into consideration.
 
> > There must be two threads, because we must always select for
> > reading, but for writing only if the output is enabled.  So if you
> > resume output after it has been stopped, the thread might be stuck
> > in a select for reading, which we can not interrupt.
> 
> But, why do you think a select for reading cannot be interrupted?

Mmmh.  There probably is a way, but I am not aware of it.  Note that I was
thinking about using io_select, not the glibc select function.

> Still, I think two separate threads and no select is better anyway.

I agree, but I don't mind to know about the wore alternative either ;)
 
> > > Now, under the transparency principle (1) above, if the underlying
> > > port is a terminal, it should DTRT.  What do terminals do when carrier
> > > drops?
> > 
> > That's a good question.  Some terminals seem to return EIO on subsequent
> > writes.
> 
> Actually, Posix specifies it exactly.  You get a SIGHUP, and if that
> didn't kill you, you get EIO on future writes.  (There are perhaps a
> couple more wrinkles.)  EIO is not a reliable indicator of carrier
> drop, because it can be caused by any number of things. 

[...]

Mmmh.  Interesting, and I see how term does this to the user.  But how 
would the underlying node inform the bottom handler about it (in the
transparent model).
 
> This is a little roundabout, but should work.  I would also not have
> an objection to adding a more direct interface to tioctl.defs or some
> other appropriate place.

I could only think of registering some port to the terminal, so that it can
send a message to the bottom handler asynchronously.  This can probably be
done via sig_post, too.   But I am not sure I have understood this correctly
yet.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de