Date: Tue, 26 Aug 2003 01:00:44 +0200
From: Alex Riesen <fork0@users.sf.net>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org, William Lee Irwin III <wli@holomorphy.com>
Subject: Re: [PATCH]O18.1int
Message-ID: <20030825230044.GA27016@steel.home>
Reply-To: Alex Riesen <fork0@users.sf.net>
References: <200308231555.24530.kernel@kolivas.org> <20030825102133.GA14402@Synopsys.COM> <20030825210254.GA12781@steel.home> <200308260848.23538.kernel@kolivas.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200308260848.23538.kernel@kolivas.org>
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1316
Lines: 25

Con Kolivas, Tue, Aug 26, 2003 00:48:23 +0200:
> > Afaics, the application (rxvt) just sleeps at the beginning waiting for
> > input from X. As every terminal would do. At some point its inferior
> > process finishes, but it fails to notice this spinning madly in the
> > internal loop calling select, which returns immediately (because other
> > side of pty was closed. That is the error in rxvt). Probably it has
> > accumulated enough "priority" up to this moment to block other
> > applications (window manager, for example) when it suddenly starts running?
> 
> Something like that. Interesting you point out select as wli was 
> profiling/tracing the mozilla/acroread plugin combination that spins on wait 
> and also found select was causing grief. It was calling select with a 15ms 
> timeout and X was getting less than 5ms to do it's work and respond and it 
> was repeatedly timing out. Seems a common link there.
> 

Yes, looks similar. Probably a simplier test could be to let the
program loop using select on stdin with zero timeout (it is a pty
usually :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/