
Whose xterm is it anyway? - ingve
http://www.tedunangst.com/flak/post/whose-xterm-is-it-anyway
======
GauntletWizard
I was 'shocked' to discover a few months back that, when I made the horrible
mistake of starting a job that wasn't easily Ctrl+C killable and dumped a lot
of output to the screen, I was better off paging to antoher desktop and
waiting for it to go away, because the limiting factor to the data-dump wasn't
the bandwidth between my machine and the remote, nor the buffer size of the
terminal, socket, or whatever else in between, but the _speed at which my
terminal rendered text_ , which was rendered moot by being on another desktop
where the text didn't need to be rendered and the xterm (or also iterm)
session could page-past that text without disturbing my desktop display.

It makes a lot of sense. Much goes into your text rendering beyond what was
necessary in your VT100. Every screen I see is anti-aliased, horizontally and
vertically aligned, with 'lines' of text that can wrap or be colored or myriad
other things according to the byzantine and arcane standards of the escape
codes and ones that have come after. Re-drawing even a fairly large amount of
text is fairly non-trivial cpu and gpu time. I found I got way better
performance and less lag from my machine if I disabled the alpha transparency
on my terminal windows. Processing power is very high, but still far from
unlimited.

~~~
Aissen
If you're using Linux, I'd advise you to use a fast terminal like Terminology;
it even has GPU acceleration, but I doubt you'd need that. The only one that
comes close on CPU-rendering speed is urxvt.

~~~
hyyypr
Pulling _all_ Enlightenment[1] dependencies just for a terminal emulator is a
waste of time and space.

Why would I use that instead of rxvt ?

1:
[https://www.enlightenment.org/?p=about/terminology](https://www.enlightenment.org/?p=about/terminology)

~~~
Flow
Tell that to the guy above who uses a Linux VM just to get a speedy terminal.
:)

~~~
e12e
Well, fwiw my local Debian Jessie claimed terminology along with dependencies
(that weren't already installed) would claim 24MB. Pretty steep for a
terminal. I tried opening one each of Terminology and Sakura[s] -- and as far
as I can tell, running:

    
    
      i=0;while true; do echo $i;i=$((i+1));done
    

is, if anything, slower in Terminology. Big caveat: I've just installed kernel
4.1.6 and while I've recompiled/installed the proprietary fglrx AMD driver,
I'm not entirely convinced most OpenGL apps work as they should.

[s]
[http://www.pleyades.net/david/projects/sakura](http://www.pleyades.net/david/projects/sakura)

------
versteegen
Educational article. Is luajit becoming a tool of choice for this kind of
hacking, rather than C or perl? Seems like a library of helper functions or
some sugar could be added to make it more suitable, note the need for a
readptr function and use of tonumber()

~~~
hwh
Arguably, the FFI gives easier access to stuff (TM) than Perl would allow. C
would be easier if the aim was clear and you can just write the code down
(well, string handling is probably easier in Lua, and there's the memory
handling with GC). When the way there is what drives you instead, Lua(JIT) is
nice. Sprinkle in some print here and there, try this and that without
compiling stuff (though that is the smallest gain, I think)...

tonumber() is LuaJITs cast for pointers to integers. There are some arguments
for it to stay.

~~~
versteegen
Make sense, dynamic languages have a lot of conveniences. If having a REPL
helps, there are REPLs for interpreted C

I meant to refer to "tonumber(oldsize[0])" used to cast from a ctype size_t to
a lua number (doubles) (I missed that's it's also used for casting pointers).
Now I realise that this is needed because implicit casting from 64 bit ints to
a double would reduce precision. It's just a very minor thing that "for" loop
bounds must be lua numbers.

------
riquito
It's interesting, but wasn't `ps aux --forest` just enough?

~~~
hwh
Platform is a BSD, with no fancy-pants "ps", I guess.

~~~
JoachimSchipper
tedu is talking about OpenBSD, which doesn't have GNU ps; but OpenBSD does
have a pstree package (which should output something like
[http://s0.cyberciti.org/uploads/faq/2014/02/pstree-
outputs.j...](http://s0.cyberciti.org/uploads/faq/2014/02/pstree-
outputs.jpg)). Of course, that's less educational.

------
TeMPOraL
How about the following approach: echo "It's meeee!" > /proc/9960/fd/0, and
see on which xterm it appears?

(For those who, like me few years ago, don't know what above does - it's
writing directly into STDOUT of a process, which is available as a file
descriptor 0 in /proc/[PID]/fd).

~~~
vinkelhake
xterm's STDOUT isn't hooked up to the terminal window it shows. For a
demonstration, start one xterm, then start another from the first. Send
something to STDOUT of the second xterm and it'll appear on the first.

------
nazri1
On my linux machine I run 8-10 dedicated xterm windows, each runs a tmux
session [1]. So the way I would solve this problem for me would be to grep the
process' /proc/$pid/env for its unique identifier.

[1]
[https://github.com/holygeek/wmgr/blob/master/xterms.conf.pl....](https://github.com/holygeek/wmgr/blob/master/xterms.conf.pl.sample#L101)

------
agumonkey
I love this kind of things. It turns software [a]synchrony in a very physical
idea. I see it as similar to engine braking. The slowest part of the system in
a context will drive the 'performance'.

------
dekhn
I found this article confusion. in the xterm, just type echo $$ and reverse-
walk the pid tree to find the parent of that shell.

