Re: fatfs locking

At 29 Feb 2004 15:47:32 -0800,
Thomas Bushnell, BSG wrote:
> 
> Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:
> 
> > So, this is the main issue, and I don't feel that you have addressed
> > it at all.
> 
> Ok, thanks for your patience.  I don't mind adding an argument,
> provided the caller always knows exactly which case is being invoked,
> to tell diskfs_cached_lookup whether the lock is already held or not.
> That is, I'm comfortable provided the caller always knows whether the
> node is locked.

Yes.  The original idea was to provide the node pointer if the
directory is locked, and NULL otherwise.

> In other words, it should be described that the arg means "the caller
> already has the node locked", and not that the arg means "don't lock
> the node when you get it."
>
> I believe this is entirely consistent with what you have suggested;
> just please be sure to document it in such a way, so as not to imply
> that it's ever legitimate to omit the locking.

Yes, I think that is exactly what is required.  Now, hopefully you
won't fall off the chair when you see how many interfaces are affected
in the case of fatfs write support (as opposed to read support) ;)
Anyway, you are making Marco very happy.

Re: fatfs locking

Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:

> Yes.  The original idea was to provide the node pointer if the
> directory is locked, and NULL otherwise.

That sounds like an excellent approach.

> Yes, I think that is exactly what is required.  Now, hopefully you
> won't fall off the chair when you see how many interfaces are affected
> in the case of fatfs write support (as opposed to read support) ;)
> Anyway, you are making Marco very happy.

Nope, it's clear it requires a lot, because the flag basically has to
be propagated all the way up the call chain.  Unlike Roland, I've
never blanched at things that require "all callers changed" in the
ChangeLog.

Thomas

Re: fatfs locking

> Somebody will make a patch (Roland, do you still have your changes for
> diskfs_cached_lookup?) and either check it in (in the case of Roland)
> or post it (everybody else), and then there's another chance to
> comment on it.

I don't seem to have that in my tree any more.

Re: new libihash implementation

At Sat, 28 Feb 2004 15:20:19 -0500 (EST),
Roland McGrath wrote:
> 
> If you've tested it well, I don't have any objections.

Ok.  I remember I tested it quite a bit when having written it (in
isolation), and now I run a compiled Hurd and did several hours of
light compilation and other stuff, and so far it works well.

So, I checked it in.  commit notifications are still defunctional on
savannah, thus this mail.  The tags are:
marcus_before_ihash_rewrite
marcus_after_ihash_rewrite

I settled on uintptr_t as the integer value type.

Have fun,
Marcus

pty behaviour

Hi,

I figured out why screen doesn't support cut&paste of more than 300
characters.  This is the high watermark in term.

The pty_io_write implementation drops (flushes) all input if the queue
is suspended (qavail returns 0).  This will be the case when the high
watermark is reached.  Thus, if screen uses a single write to its pty
end when the text is pasted, only up to the first 300 characters are
written.

pty_io_write does in particular not suspend the write, wait on the
queue condition and continue after the queue is drained below the low
watermark and unsuspended.

I couldn't find a description of what pty's are supposed to do on
read/write.  However, screen seems to expect to be able to do it, and
screen is widely ported.  Actually, I tried to find out what screen is
trying to do (ie if it splits up the input in chunks etc), but the
code is a horrid mess (it's slowpaste option worked, though, IIRC, as
it sends input char by char).  Likewise I saw a perl pty test fail due
to this.

So, is there anything I am missing?  Shouldn't we implement
pty_io_write as any other writer, with suspending behaviour unless
O_NONBLOCK is set (if that is even possible for a pty)?

Thanks,
Marcus

Hey, ya! =))

I  don't bite, weah!

password  --  00022

_______________________________________________
Hurd-devel-readers mailing list
Hurd-devel-readers <at> gnu.org
http://mail.gnu.org/mailman/listinfo/hurd-devel-readers

Re: pty behaviour

Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:

> The pty_io_write implementation drops (flushes) all input if the queue
> is suspended (qavail returns 0).  This will be the case when the high
> watermark is reached.  Thus, if screen uses a single write to its pty
> end when the text is pasted, only up to the first 300 characters are
> written.

This is (or used to be) normal Unix tty behavior.  If you were on a
tty, and typed a bunch of characters which were not being read, then
when the buffer gets full, the tty driver eventually stops reading
input and beeps the bell.  So pty_io_write does just what all tty
input does in this respect.

The reason this was historically done was because of limited kernel
memory: you can't just have ever-expanding terminal buffers,
especially when they can be caused by noisy lines or the like.  If you
terminal was in line mode, this then imposed a limit on the longest
line you could type in Unix.

It indeed isn't that uncommon to have a key held down by something on
the keyboard, unattended.  (Ever had an emacs buffer get huge that
way?  I have.)  We don't want "kernel-level" services to be broken by
that kind of thing.

However, it does suck in this case!

We should certainly not change the tty behavior.  It's the Right
Thing.  Sticky keys do happen.

Re: pty behaviour

At 03 Mar 2004 18:55:52 -0800,
Thomas Bushnell, BSG wrote:
> 
> Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:
> 
> > The pty_io_write implementation drops (flushes) all input if the queue
> > is suspended (qavail returns 0).  This will be the case when the high
> > watermark is reached.  Thus, if screen uses a single write to its pty
> > end when the text is pasted, only up to the first 300 characters are
> > written.
> 
> This is (or used to be) normal Unix tty behavior.  If you were on a
> tty, and typed a bunch of characters which were not being read, then
> when the buffer gets full, the tty driver eventually stops reading
> input and beeps the bell.  So pty_io_write does just what all tty
> input does in this respect.

Maybe this is merely a matter of the right limit rather than the behaviour.

I just tried to paste a massive amount of data into screen under
GNU/Linux, and hey!  It gets stuck, flashes, and consumes 100% cpu
time for a long time (I interrupted it eventually).  So, this is
definitely worse behaviour than under the Hurd.

The test suite in the Perl IO::Tty module tested exactly for this
limit and complained about 300 being too small.  It wanted at least
512.  The limit in Linux for this perl test program was 8061 (odd
value, but what do I know).

So, if you say the behaviour is correct, and I am certainly following

Re: pty behaviour

Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:

> I just tried to paste a massive amount of data into screen under
> GNU/Linux, and hey!  It gets stuck, flashes, and consumes 100% cpu
> time for a long time (I interrupted it eventually).  So, this is
> definitely worse behaviour than under the Hurd.

Well, then gollie gee!  

> So, if you say the behaviour is correct, and I am certainly following
> your line of argumentation, then increasing the high watermark to
> something like 4k or even 8k should be fine do avoid any problems
> people wouldn't also have under GNU/Linux.

Sure, sounds fine by me.  As long as it's got a sane limit, the limit
can be high.  It's not like we are actually reserving all that much
memory--nor is it like 8k is very much memory anyhow.

Thomas

Re: pty behaviour

At 04 Mar 2004 11:20:32 -0800,
Thomas Bushnell, BSG wrote:
> > So, if you say the behaviour is correct, and I am certainly following
> > your line of argumentation, then increasing the high watermark to
> > something like 4k or even 8k should be fine do avoid any problems
> > people wouldn't also have under GNU/Linux.
> 
> Sure, sounds fine by me.  As long as it's got a sane limit, the limit
> can be high.  It's not like we are actually reserving all that much
> memory--nor is it like 8k is very much memory anyhow.

Splendid.  So, if we increase the high watermark, can we increase it
to a power of 2, to make best use of allocated memory (which is
doubled at each reallocation)?  Or is it possible that some other code
in term enqueues character even if the queue is suspended (for
whatever reason)?

The second question would be, if we increase the high watermark, it
seems to make sense to also increase the low watermark, to improve
flow control.  Any advice for this?

Thanks,
Marcus