Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Apr 2008 21:14:53 +0200
From:      Ed Schouten <ed@80386.nl>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        arch@freebsd.org
Subject:   Re: f_offset
Message-ID:  <20080414191453.GK5934@hoeg.nl>
In-Reply-To: <5287.1208159704@critter.freebsd.dk>
References:  <20080414074710.GI5934@hoeg.nl> <5287.1208159704@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

--Ht+/lPZLak6eP81R
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Poul-Henning,

Sorry, I forgot to reply to your message this afternoon.

* Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <20080414074710.GI5934@hoeg.nl>, Ed Schouten writes:
>=20
> >I'm experiencing similar problems with implementing read() and write()
> >inside my mpsafetty branch for TTY's. Just like the current TTY
> >implementation, my implementation will do strange things when two
> >threads call read() or write() at the same time. Data could end up mixed
> >together.
>=20
> The write side of this will break quite a lot of stuff, starting
> with syslogd(8), write(1), wall(1) and similar, all which expect
> to be able to spam terminals coherently.
>=20
> The read side will probably mostly cause trouble for programs that
> try to take input from /dev/tty, usually passwords.

I'll explain what I've done with the TTY layer somewhat more in depth. I
was a little brief in my last message.

It is true that the read()-side of the TTY layer doesn't really offer
much guarantees when multiple applications try to perform a read() on
both the TTY device or the PTY controller device. I've tried to prevent
as much copying as possible, so unlike the current code there isn't a
buffer in between. A compromise I had to make was that read()'s on TTY's
aren't serialized. I don't think this will cause a problem:

- PTY controller devices aren't really intended to be read()
  by multiple threads at the same time.

- It's not likely multiple read()'s on the TTY device will happen a lot.
  When a background process group tries to perform a read(), it will
  most likely receive a SIGTTIN (except when it ignores the signal,
  etc).

- I am sure this will not cause any problems in canonical mode, because
  there is already a guarantee that the VEOL/VEOF character will always
  be processed by the thread that first detected it. It is not possible
  that the character is interpreted by multiple readers.

Now about the write() case. I said write()'s were completely
unprotected, but I was a little brief about this. Because it's too
complex to implement an unbuffered mechanism that copies data from
userspace directly into the buffer queue (makes locking hard, input
could be processed to expand to a different amount of bytes, etc),
write() calls will be buffered.

There are only two cases where a write() may end up fragmented when
multiple write() calls would happen at the same time:

- The write() exceeds the write buffer size of 256 bytes (100 bytes with
  the current TTY layer). Maybe I should adjust this value, because 256
  bytes may be a lot when allocated on the stack.

- The write() call causes the calling thread to be blocked, because the
  TTY has reached its high watermark.

All in all I think the way I've implemented the TTY layer should be
quite safe. Its guarantees don't differ too much when compared to the
existing implementation, in my opinion.

--=20
 Ed Schouten <ed@80386.nl>
 WWW: http://g-rave.nl/

--Ht+/lPZLak6eP81R
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)

iEYEARECAAYFAkgDrS0ACgkQ52SDGA2eCwX8kACdHbYeBzOOtqEHDiJwRZ+NsLKz
OssAniUX/VbObXglktgx1EHEVBeacJsM
=+YxA
-----END PGP SIGNATURE-----

--Ht+/lPZLak6eP81R--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080414191453.GK5934>