[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r100961: Enable ICANON (Bug#6771)

From: Stefan Monnier
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r100961: Enable ICANON (Bug#6771). Any long line problem must be solved differently.
Date: Fri, 06 Aug 2010 15:03:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> I agree with the commit that reverts my ICANON change.  Yet:
>>> There is AFAIK no bug report or test case for the long line problem.
>> AFAIK, the missing bug-report is the one that shows the ills of sending
>> EOFs, while the bug-report for long-lines is bug#6149, which should be
>> re-opened.

> As I said in relation to this, I could not reproduce the error in 6149.

I could and still can:

  emacs -Q
  M-x shell
  SPC C-u 5000 a
  | wc

and instead of getting wc's output I just get 4090 "a"s
(the command appears to get cut at 4096 chars).  The shell is `zsh', but
last time I tried, the result was the same with bash.

>> Could you spell out more precisely how it's different from what we do
>> now: we already check emacs_write's output to see if the buffer is full,
>> in which case we wait, don't we?

> Yes, but we wait a small time and then try to write again (if I read the
> code correctly).  If nobody is reading, that can turn into a (sort of)
> busy wait.
> The point of handing it off to select is then we don't write until we know
> we can write something.

So this doesn't explain the loss of chars, it would only cause
a performance problem.

>> IIUC VMIN and VTIME not only are specific to the non-ICANON mode, but
>> also they use the same slot as some of the other settings (specifically
>> the slots may be shared with VEOL and VEOF, according to my manpage).
> That is correct.

Thanks for confirming, I've fixed it already,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]