Forum comments in chronological order
Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.
Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.
- Jun 2007
- Aug 2007
- Oct 2007
- Nov 2007
- Dec 2007
- Jan 2008
- Feb 2008
- Mar 2008
- Apr 2008
- May 2008
- Jun 2008
- Jul 2008
- Aug 2008
- Sep 2008
- Oct 2008
- Nov 2008
- Dec 2008
- Jan 2009
- Feb 2009
- Mar 2009
- Apr 2009
- May 2009
- Jun 2009
- Jul 2009
- Aug 2009
- Sep 2009
- Oct 2009
- Nov 2009
- Dec 2009
- Jan 2010
- Feb 2010
- Mar 2010
- Apr 2010
- May 2010
- Jun 2010
- Jul 2010
- Aug 2010
- Sep 2010
- Oct 2010
- Nov 2010
- Dec 2010
- Jan 2011
- Feb 2011
- Mar 2011
- Apr 2011
- May 2011
- Jun 2011
- Jul 2011
- Aug 2011
- Sep 2011
- Oct 2011
- Nov 2011
- Dec 2011
- Jan 2012
- Feb 2012
- Mar 2012
- Apr 2012
- May 2012
- Jun 2012
- Jul 2012
- Aug 2012
- Sep 2012
- Oct 2012
- Nov 2012
- Dec 2012
- Jan 2013
- Feb 2013
- Mar 2013
- Apr 2013
- May 2013
- Jun 2013
- Jul 2013
- Aug 2013
- Sep 2013
- Oct 2013
- Nov 2013
- Dec 2013
- Jan 2014
- Feb 2014
- Mar 2014
- Apr 2014
- May 2014
- Jun 2014
- Jul 2014
- Aug 2014
- Sep 2014
- Oct 2014
- Nov 2014
- Dec 2014
- Jan 2015
- Feb 2015
- Mar 2015
- Apr 2015
- May 2015
- Jun 2015
- Jul 2015
- Aug 2015
- Sep 2015
- Oct 2015
- Nov 2015
- Dec 2015
- Jan 2016
- Feb 2016
- Mar 2016
- Apr 2016
- May 2016
- Jun 2016
- Jul 2016
- Aug 2016
- Sep 2016
- Oct 2016
- Nov 2016
- Dec 2016
- Jan 2017
- Feb 2017
- Mar 2017
- Apr 2017
- May 2017
- Jun 2017
- Jul 2017
- Aug 2017
- Sep 2017
- Oct 2017
- Nov 2017
- Dec 2017
- Jan 2018
- Feb 2018
- Mar 2018
- Apr 2018
- May 2018
- Jun 2018
- Jul 2018
- Aug 2018
- Sep 2018
- Oct 2018
- Nov 2018
- Dec 2018
- Jan 2019
- Feb 2019
- Mar 2019
- Apr 2019
- May 2019
- Jun 2019
- Jul 2019
- Aug 2019
- Sep 2019
- Oct 2019
- Nov 2019
- Dec 2019
- Jan 2020
- Feb 2020
- Mar 2020
- Apr 2020
- May 2020
- Jun 2020
- Jul 2020
- Aug 2020
- Sep 2020
- Oct 2020
- Nov 2020
- Dec 2020
- Jan 2021
- Feb 2021
- Mar 2021
- Apr 2021
- May 2021
- Jun 2021
- Jul 2021
- Aug 2021
- Sep 2021
- Oct 2021
- Nov 2021
- Dec 2021
- Jan 2022
- Feb 2022
- Mar 2022
- Apr 2022
- May 2022
- Jun 2022
- Jul 2022
- Aug 2022
- Sep 2022
- Oct 2022
- Nov 2022
- Dec 2022
- Jan 2023
- Feb 2023
- Mar 2023
- Apr 2023
- May 2023
- Jun 2023
- Jul 2023
- Aug 2023
- Sep 2023
- Oct 2023
- Nov 2023
- Dec 2023
- Jan 2024
- Feb 2024
- Mar 2024
- Apr 2024
- May 2024
- Jun 2024
- Jul 2024
- Aug 2024
- Sep 2024
- Oct 2024
- Nov 2024
- Dec 2024
Dec 2008
Anonymous
Wed 10-Dec-2008 12:27
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
Keep doing things like this please...
Excelente!
Muchas Gracias
Fede Tula
eidolon88
luca c
Thu 11-Dec-2008 18:07
luca c
Thu 11-Dec-2008 18:07
You are a Genius!! I admire you and your works.
From the Sicily (Italy)
From the Sicily (Italy)
Anonymous
Fri 12-Dec-2008 15:26
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!
Hur lång tid tog det att implementera?
Återigen riktigt snyggt!
Anonymous
Fri 19-Dec-2008 00:06
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!
http://galway.c64.org/~sid/Kryo_Chiptune.sid
Thanks for the great inspiration!
Anonymous
Sat 20-Dec-2008 02:24
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
Best to all,
karl@freefriends.org
Anonymous
Sat 20-Dec-2008 05:20
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.)
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
Thu 25-Dec-2008 19:19
good job & best introductory for TTY