If there is a truly unstoppable loop (considering usage of the word "may" or such optional ability to continue or break a loop) then the game is considered a tie. There are tournament rules regarding players intentionally drawing out the game (it's against the rules), but I don't think there's any rule against a deck that simply runs long (or really long).
Some cards have been banned for causing tournament rounds to run too long, or for being central in decks that regularly do this (I believe Sensei's Divining Top and the "eggs" deck were the major offenders).
Tournaments run with a time limit. After the time limit, the game ends in a set number of turns. There are also rules for "slow play" that generally keep a single turn from lasting too long—and inadvertently prevent certain weird combinations of cards from working.
Online play has what is effectively a chess clock. This doesn't work in person because the game involves "priority" passing between players after every single action, which would be difficult to do manually. Additionally, play in person relies on a whole bunch of "shortcuts" that skip steps if both players don't want to do anything, which would make timekeeping even more difficult.
But if you left out these tournament-specific rules and just played the game rules, you could have games going on arbitrarily long. Since you can create "tokens" you can have arbitrary amounts of state, so a game could even loop without ever hitting the same game state twice. (Think "puffer trains" from the John Conway's Game of Life.)
Someone want fill me in on the piece of popular culture I apparently missed? All I've got is either "an agreement" or compilers for ancient IBM mainframes (704s, I think it was?).
You take away what your bring to the party, I guess. I read it as "we all succeed or fail together", and it wasn't until I read hackernews outrage it occurred to me someone would deliver another interpretation.
Insensitive to survivors. I don't find it disgustingly insensitive, rather potentially troublesome.
Also, yes, master / slave is outdated. If you are developing a new product, do not use master / slave terminology. It is not appropriate for professional work product.
Daemon is troublesome in many households for young hackers, which I don't advocate changing; this just makes me a little sad.
Killing, I have no problem with, but I'm an American. If I were, say Austrian, I might prefer terminating processes.
---
The whole point of PC (political correctness) is to take power away from racists, sexists and other -ists by demonizing words and concepts. I think this has obviously gone too far in many areas. For instance, people should be able to discuss slavery, racism, violence, etc in a grown-up environment without fear of undue reprisal. If someone is still an actual racist shithead then they deserve the consequences of their free speech.
Speech and names should be respectful, especially in the professional arena. Being witty is fun, but causing real pain is not. Some people are killjoys who pounce on every troublesome or ambiguous potential "trigger" word. Some people are assholes who don't believe words can cause real pain - or worse - enjoy negging, controlling, and demeaning.
Personally, I tell horrible jokes and say mean things about people pretty often, but only verbally, and only to small audiences who take them in the manner intended. I'm sure I say hurtful things in amongst the jokes sometimes, but I also try to show respect in most of my dealings as well.
True, but do you think that is the point OP was making? "Members of a particular country should have a preference for a word that is associated with an individual from that country" seems like a rather strange linguistic argument to make :-)
Your first comment reads like if it was serious though, sorry. I suggest use '/s' for this situations, even though it's a bit lame to have to denote sarcasm. Also, the head of the thread is flagged out, so people who took yours seriously probably thought that you made that comment.
That's actually a pretty good question. I would guess that killing is so generic from the News, games, movies, etc that killing doesn't usually strike a personal chord - whereas family and friends of suicide victims[1] tend to take suicide personally.
1. Typing that out reinforces how weird it is to think about suicide terminology - a subject one would be advised to not spend too much time pondering.
I'm sorry, but I disagree with this current trend of making language "safe" for everyone. Yes, I know about triggers and some good reasons for changing words (there's no real reason to be using master/slave in a new piece of software).
Eventually you end up with bland, uninteresting language. Pact, while a little confronting if you follow the connotations far enough, is an excellent and succinct name.
spitballing here - some of these may be more offensive than pact, included to get mental juices flowing. Also, not looking these up for dupes in current use.
mad - mutually assured destruction
mat - mut. ass. termination
jenga
atdi - atomic disintegrator
dms - dead mans switch
psd - process safety device
vigil - alert watching
turret - are you still there
ff - fail fast
faro - the pharoah gets buried with his servants
tact - terminal action
pact - positive action (same name, different story)
I see why you were downvoted for the initial comment, but I don't see why you are being downvoted for this one. This seems like a creative list of alternatives to back your complaint. Personally I don't think the name should change at all. Although, I do like ff for the alternative name you could give it in your head that describes the exclamations of the processes involved. Upvoted for creativity and constructivity.
It doesn't kill the shell, when one of the process dies but kills the processes if shell dies. There is some trick involved in the way trap gets called though when shell dies and without waiting on the processes twice - shell exits without killing child processes.
I might be totally wrong, but isn't this a good way to get orphaned processes? Kill the parent arbitrarily with SIGTERM (I don't think this automatically cleans up the children/forked processes) and viola, you've got an orphaned process.
Using this would require whatever process you start to handle SIGTERM properly. Most processes spawning children do this, but it's no guarantee and one needs to be aware of this.
In my experience, processes doing IPC with parent gets notified of parental death by EOF on the socketpair/pipe it's using to communicate with the parent. This is easy to reason about and most people check return values from I/O functions. Parents spawning children and only caring about SIGCHLD are more prone to not have the correct signal handlers set up by its dev(s).
IMO, any process spawning children w/o proper signal handlers are not good citizens.
We can also call it hitler as it does a 'process genocide'. Or maybe we can use a proper name like 'killtogether' or 'killpg' for kill process group. The name should correlate to the function of the thing.
You're right, but I think it's an acceptable risk.
pact wakes up every second to check that every process is still there. If the process is gone, it sets the procChanged field in the struct, and it won't kill it later.
Still, what you are doing is inherently racy. The very moment you pass the PIDs to your program, they can already be gone and reused. You can end up kill()ing a different PID. I don't think you can use this for anything serious.
In what situation do you think it might be acceptable?
EDIT: You are trying to implement process groups in user space.
This is the service supervision approach, which is indeed the best, avoiding race conditions and nasty polling. If you really must monitor processes which you cannot parent, at least under Linux you can do this using ptrace to sort-of-reparent the processes (as long as you have CAP_SYS_PTRACE or your ptrace scope is set to 0 in Yama), with waitpid to monitor all of them.
If you happen to target Windows platform (I know article does not), don't reinvent the wheel. There are NT Job Objects [1] for this. The 'target' process creates the job with `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` set and keeps the job handle open. 'dependend' processes (by default all children spawned by 'target', but you can add more) will all be killed when the 'target' process terminates, no matter how is terminated. Jobs can do more, like cap CPU/IO/Memory for the job.
80 comments
[ 4.6 ms ] story [ 124 ms ] threadhttp://www.erlang.org/doc/design_principles/sup_princ.html
http://gatherer.wizards.com/Pages/Card/Details.aspx?multiver...
I wonder if there's anything in the rules to deal with the fact that a game might never complete.
Online play has what is effectively a chess clock. This doesn't work in person because the game involves "priority" passing between players after every single action, which would be difficult to do manually. Additionally, play in person relies on a whole bunch of "shortcuts" that skip steps if both players don't want to do anything, which would make timekeeping even more difficult.
But if you left out these tournament-specific rules and just played the game rules, you could have games going on arbitrarily long. Since you can create "tokens" you can have arbitrary amounts of state, so a game could even loop without ever hitting the same game state twice. (Think "puffer trains" from the John Conway's Game of Life.)
A pact, from Latin pactum ("something agreed upon"), is a formal agreement.
This lets you change behavior in a running process from the shell by triggering a desired handled signal.
"pact with the devil" is another negative twist.
What about 'killing a process'?
What about 'master / slave' relationships?
Terms get used for purposes other than offending people
Also, yes, master / slave is outdated. If you are developing a new product, do not use master / slave terminology. It is not appropriate for professional work product.
Daemon is troublesome in many households for young hackers, which I don't advocate changing; this just makes me a little sad.
Killing, I have no problem with, but I'm an American. If I were, say Austrian, I might prefer terminating processes.
---
The whole point of PC (political correctness) is to take power away from racists, sexists and other -ists by demonizing words and concepts. I think this has obviously gone too far in many areas. For instance, people should be able to discuss slavery, racism, violence, etc in a grown-up environment without fear of undue reprisal. If someone is still an actual racist shithead then they deserve the consequences of their free speech.
Speech and names should be respectful, especially in the professional arena. Being witty is fun, but causing real pain is not. Some people are killjoys who pounce on every troublesome or ambiguous potential "trigger" word. Some people are assholes who don't believe words can cause real pain - or worse - enjoy negging, controlling, and demeaning.
Personally, I tell horrible jokes and say mean things about people pretty often, but only verbally, and only to small audiences who take them in the manner intended. I'm sure I say hurtful things in amongst the jokes sometimes, but I also try to show respect in most of my dealings as well.
Why do you feel that Austrians have a special sensitivity to the term "killing"?
He makes no point.
I had more silliness in the comment, but I removed it, so the tone is kinda weird right now.
1. Typing that out reinforces how weird it is to think about suicide terminology - a subject one would be advised to not spend too much time pondering.
Eventually you end up with bland, uninteresting language. Pact, while a little confronting if you follow the connotations far enough, is an excellent and succinct name.
I would have also accepted "contract".
If any link is severed, no more chain.
mad - mutually assured destruction
mat - mut. ass. termination
jenga
atdi - atomic disintegrator
dms - dead mans switch
psd - process safety device
vigil - alert watching
turret - are you still there
ff - fail fast
faro - the pharoah gets buried with his servants
tact - terminal action
pact - positive action (same name, different story)
fact - final action
rapture - it's time
raptor - they hunt in packs
coterm - coterminous https://www.google.com/search?q=coterminous
Edit: also, dms? o_O ...
I did say some of them were worse...
It doesn't kill the shell, when one of the process dies but kills the processes if shell dies. There is some trick involved in the way trap gets called though when shell dies and without waiting on the processes twice - shell exits without killing child processes.
I can see how I would use it in supervisord within a group.
In my experience, processes doing IPC with parent gets notified of parental death by EOF on the socketpair/pipe it's using to communicate with the parent. This is easy to reason about and most people check return values from I/O functions. Parents spawning children and only caring about SIGCHLD are more prone to not have the correct signal handlers set up by its dev(s).
IMO, any process spawning children w/o proper signal handlers are not good citizens.
If allusions to suicide pacts are fair game, so is mass killing; and atomic means "all or nothing" in CS.
I debated about making it send SIGKILL shortly after sending SIGTERM, but I was having troubling thinking of an unsurprising way to implement it.
(A process monitoring system will mostly trigger under odd conditions... such as fork bombs.)
pact wakes up every second to check that every process is still there. If the process is gone, it sets the procChanged field in the struct, and it won't kill it later.
Basically you write simple shell script to start your processes and at the and you exec prace so it takes over children of shell:
You could also do this as a part of shell script in this way: Then prace has simple job. It wait(2)s and then kills all children.I have it somewhere if someone is interested, but I can access it in few hours. But everything is written in at most 2/3 terminal screens worth of C.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...