Forum comments in chronological order

Anonymous
Wed 10-Dec-2008 12:27

I really admire you!! I'm not use to post, but this article was by far the best I ever read about tty, i read many articles and even books but nothing so clear like this.
Keep doing things like this please...

Excelente!
Muchas Gracias
Fede Tula

eidolon88
luca c
Thu 11-Dec-2008 18:07

You are a Genius!! I admire you and your works.

From the Sicily (Italy)

Anonymous
Fri 12-Dec-2008 15:26

Riktigt snyggt. Tror jag ska ta o bygga mej en sån själv så att jag verkligen kan visa hur kraftig en liten mega är.

Hur lång tid tog det att implementera?

Återigen riktigt snyggt!

Anonymous
Fri 19-Dec-2008 00:06

For the fun of it, I've made a SID version of the tune:
http://galway.c64.org/~sid/Kryo_Chiptune.sid

Thanks for the great inspiration!

Anonymous
Sat 20-Dec-2008 02:24

Does anyone happen to know the origin of the piece, and/or why it has the name Fratres? I've never come across this in my readings about Part and I am very curious, it being one of my favorite pieces to listen to (and play).
Best to all,
karl@freefriends.org

Anonymous
Sat 20-Dec-2008 05:20

Good article. A few years ago, after some experimentation, I wrote up some TTY stuff for myself, because I couldn't find any good documentation. For example, I never understood why process group leaders (and consequently also session leaders) are prevented from calling setsid(2). (See the manual for what setsid(2) does.) I think I can explain it now.

The process P is a pg leader if P.PID = P.PGID. In the example of the article, "Job" means process group, and ls (103) is a process group leader:

ls.PID = 103
ls.PGID = 103
ls.SID = 101
ls.CTTY = /dev/pts/0

Suppose we allow ls to call setsid(2). This would have the following consequences:

ls.PID = 103 # unchanged
ls.PGID = 103 # set to ls.PID, but in fact this is no change!
ls.SID = 103 # set to ls.PID
ls.CTTY = <none>

Now ls is session leader (ls.SID = ls.PID), and ls is process group leader (ls.PGID = ls.PID).

At this point, however, sort (104) would belong to a process group (103) whose leader's (ls's) SID (103) doesn't match sort's SID (101)!

sort.PID = 104
sort.PGID = 103
sort.SID = 101

the pg leader for pg 103 is ls (103):
ls.PID = ls.PGID = 103 = sort.PGID
however
ls.SID = 103 != 101 = sort.SID

We have two processes in the same process group belonging to different sessions!

ls is prevented from calling setsid() because as current process leader its PGID doesn't change when it is set to its PID, while its SID changes. Thus it would leave the session while staying in the process group.

Sort, OTOH, can call setsid(), becuase it also leaves the process group:
sort.PID=104
sort.PGID=104 # leaves process group too
sort.SID=104
sort.CTTY=<none>

fork(2)-ing and calling setsid(2) in the child helps, because the child gets a new PID, which will be different from any PGID of the parent (as that PGID was the PID of some process), and so when the child calls setsid(2), the child.PGID := child.PID operation will actually change the child's inherited PGID and so the child will be able to leave the process group.

Right after fork():
parent.PGID = some_old_PID
child.PID = new_PID
child.PGID = parent.PGID = some_old_PID

The child calls setsid():
child.PGID = child.PID = new_PID != some_old_PID = parent.PGID

A session leader *could* call setsid(), despite also being a process group leader, since neither its PGID nor its SID would change. However, its CTTY would be set to <none>, and this would result in a situation where the original controlling process (= a session leader with a CTTY), for example, your shell, has no more access to the terminal!

Furthermore, there is the rule that when a controlling process dies, each session member (each process P with P.SID = SL.SID) loses access to the terminal (and possibly get a SIGHUP on the next read/write). This clearly shows the intent that no session member shall have access to the terminal when the session leader has none. This principle would be violated if the current session leader could detach from the CTTY by calling setsid(). (Or all session members would have to lose access to the CTTY, just as if the session leader died.)

Anonymous
Thu 25-Dec-2008 19:19

good job & best introductory for TTY