| From: Thomas Dickey <[EMAIL PROTECTED]>
| Reply-To: [EMAIL PROTECTED]
| To: [EMAIL PROTECTED]
| Subject: Re: xterm can hang, CPU bound
|
| On Mon, Feb 03, 2003 at 07:59:49PM -0500, D. Hugh Redelmeier wrote:
| > Might be worth doing an strace. On RHL8.0, I get:
| >
| > select(5, [3 4], [], NULL, {0, 0}) = 1 (in [3], left {0, 0})
| > select(4, [3], [], [], {0, 0}) = 1 (in [3], left {0, 0})
| > select(4, [3], [], [], {0, 0}) = 1 (in [3], left {0, 0})
| > select(4, [3], [], [], {0, 0}) = 1 (in [3], left {0, 0})
| >
| > Notice that each of these select calls has a timeout specified, and
| > that timeout is 0 seconds. So these calls never block. Besides that,
| > there is something available on file descriptor 3 but it is never
| > being accessed.
| >
| > What does strace show on your older system?
|
| I guess the comparable chunks are like this:
|
| select(6, [4 5], [], NULL, {0, 0}) = 1 (in [4], left {0, 0})
| select(5, [4], [], [], {0, 0}) = 1 (in [4], left {0, 0})
| select(5, [4], [], [], {0, 0}) = 1 (in [4], left {0, 0})
| select(5, [4], [], [], {0, 0}) = 1 (in [4], left {0, 0})
That sure looks like it ought to eat all available CPU.
None of those calls should block.
| > | > What do you think about the approach I suggested (act as if a default
| > | > CSI...T sequence had been received until the real one is)? Perhaps
| > | > the default should only be used after some timeout.
| > |
| > | it's not entirely clear to me what the sequence would be here.
| >
| > Two obvious ones: the whole xterm region, or an empty region at the
| > point of the cursor. I'd vote for the empty region: no information
| > about a subsequent click is lost (the answer will be forced to be the
| > long form).
| >
| > Clearly func should be non zero in either case: we don't want to
| > cancel the mode.
| >
| > I do suggest that the default only be installed after a brief timeout.
| > How long? A tenth of a second feels about right.
| >
| > I also suggest that the default be replaced if and when the explicit
| > CSI...T sequence is received.
|
| It sounds as if you're proposing to make it return a dummy escape sequence -
| or make the escape sequence terminate automatically after a short time -
| but it's not clear to me
Sorry, I'll try to be clearer.
When a button is pressed in mouse hilite tracking mode,
xterm sends ESC [ M Cb Cx Cy to the PTY
xterm awaits ESC ... T from the PTY, doing nothing else.
The ESC [ Ps ; Ps ; Ps ; Ps ; Ps T informs xterm:
func: non zero to initiate hilite tracking and 0 to abort
startx, starty: starting location for highlighted region
firstrow, lastrow: limits for tracking
I'm proposing that until the ESC ... T message is received from
through the PTY, the xterm should act as if it had received something
like: ESC [ 1 ; curx ; cury ; currow ; currow T
This would be provisional. When (if) an ESC ... T is actually received,
it should override this default.
Thus xterm would not hang. There should be no compatibility problem
UNLESS the button release arrives before the actual ESC ... T. The
reason I suggested a small delay before acting on the default is to
avoid the race most times.
The ESC ... T is not sent from xterm. So no, I'm not suggesting that
it send it now. Only that it act as if it received one.
Note: the provisional ESC ... T sequence I propose has not been
tested. Maybe something is not quite right. I hope the idea is OK.
Perhaps the firstrow/lastrow should cover the whole xterm window.
Hugh Redelmeier
[EMAIL PROTECTED] voice: +1 416 482-8253
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
