Subj : Re: How to manage time-slicing in Pthreads programs? To : comp.programming.threads From : David Schwartz Date : Sun Feb 20 2005 04:16 pm "Marcin 'Qrczak' Kowalczyk" wrote in message news:87ekfbq809.fsf@qrnik.zagroda... > "David Schwartz" writes: >> Obviously, you need a way to interrupt a broken program in a very >> harsh >> way. But for normal termination, the program has to process the shutdown >> request politely anyway. Allowing ^C to have its default behavior of >> terminating the program ungracefully is adequate in only trivial >> programs. > The model of explicit checking for the request can be implemented in > terms of Unix signals: the signal handler sets a flag and the program > checks the flag from time to time. Yes, except this is an ugly way to do it. For one thing, you have to deal with the interruption of system calls. For another thing, you have to globally keep track of who is waiting for what signals or your signal handlers all step on each other. > The converse is not true. The converse may or may not be true depending upon what features our hypothetical implementation provides. > So the OS should provide Unix signals. I'm not saying the OS shouldn't have a way to deliver asynchronous messages to a process for cases where that's needed. Cases obviously include terminating a program abnormally due to external factors. Similarly, internal factors (access violation, I/O error on swap device) may force a program to terminate in a way that is synchronous to something the program did. What I am saying, however, is that the Unix signal model is really, really bad. It's wrong for things like graceful termination or writes to broken pipes, it's wrong for socket discovery, it's wrong for inter-thread communication. There is nothing wrong with a default behavior or ungraceful asynchronous termination for a program that doesn't know how to handle these things better. DS .