unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: kai.grossjohann@gmx.net (Kai Großjohann)
Subject: Re: Any idea about what makes Emacs slow reading on pipes?
Date: Mon, 19 May 2003 09:33:39 +0200	[thread overview]
Message-ID: <84r86vz8z0.fsf@lucy.is.informatik.uni-duisburg.de> (raw)
In-Reply-To: x565o8vy0z.fsf@lola.goethe.zz

David.Kastrup@t-online.de (David Kastrup) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     We might change it so that, after stashing the stuff in a
>>     buffer, Emacs looks again if more data is available from the
>>     same process.
>
> More data will not be available from the same process, since the
> process has not had any chance to get CPU time again for generating
> more data.  We are talking about a uniprocessor machine here.

I'm not familiar with the internals of Unix (-like) systems, but maybe
it is possible to "look" in such a way that the scheduler has a chance
to do its thing.  For example, say that using select(2) causes the
scheduler to run, then we might "look" using select(2).

Hm.  But this might make Emacs quite a bit slower.  So maybe it is a
good idea to only look twice if little data has been received.  If a
lot of data has been read, then we can just process that immediately.
-- 
This line is not blank.

  reply	other threads:[~2003-05-19  7:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-16 13:08 Any idea about what makes Emacs slow reading on pipes? David Kastrup
2003-05-16 13:55 ` Andreas Schwab
2003-05-16 17:18 ` Kevin Rodgers
2003-05-16 17:34   ` David Kastrup
2003-05-16 18:38     ` Kevin Rodgers
2003-05-16 18:49       ` David Kastrup
2003-05-16 17:48 ` Jan D.
2003-05-16 18:38   ` David Kastrup
2003-05-16 20:23     ` Jan D.
2003-05-16 21:00     ` Andreas Schwab
2003-05-16 23:17     ` Satyaki Das
2003-05-17  1:50     ` Kim F. Storm
2003-05-17  0:34       ` David Kastrup
2003-05-18  0:31         ` Kim F. Storm
2003-05-17 23:07           ` Stefan Monnier
2003-05-17 23:39           ` David Kastrup
2003-05-18  2:09             ` Stefan Monnier
2003-05-18  8:45             ` Kai Großjohann
2003-05-18 10:12               ` David Kastrup
2003-05-18 19:04               ` Richard Stallman
2003-05-18 19:46                 ` David Kastrup
2003-05-19  7:33                   ` Kai Großjohann [this message]
2003-05-19  8:24                     ` David Kastrup
2003-05-18  8:46             ` Kai Großjohann
2003-05-18 10:03               ` David Kastrup
2003-05-18 15:09                 ` Kai Großjohann
2003-05-18 15:36                   ` David Kastrup
2003-05-18 15:50                     ` Kai Großjohann
2003-05-18 16:28                       ` David Kastrup
2003-05-19  7:26                         ` Kai Großjohann
2003-05-19  8:09                           ` David Kastrup
2003-05-18 19:03           ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84r86vz8z0.fsf@lucy.is.informatik.uni-duisburg.de \
    --to=kai.grossjohann@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).