Subj : Re: How to manage time-slicing in Pthreads programs? To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Mon Feb 21 2005 10:13 am "David Schwartz" writes: >> 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. In my case interruption of system calls is a benefit: it allows for other threads to be run or for a signnal to be handled in a safe point if an interruptible system call would take too long. (I can't just use OS threads because an efficient multithreaded GC is too hard, because they don't scale to a large number of threads, and because it would require too much synchronization in various places - currently each C snippet is automatically a critical section, which is useful for making some primitives safe.) > 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. I don't understand. OS-level signal handlers stay the same all the time. They change global volatile variables. The effect of those variables can be different in different parts of a program, as code establishes different handlers for translated Unix signals. The only bad thing is that it makes hard to combine parts written in various languages, if all runtimes want to use signals for their purposes. The only signal which my implementation needs for itself is a timer howewer, other signals are handled only to pass control to handlers established by the program. >> The converse is not true. > > The converse may or may not be true depending upon what features our > hypothetical implementation provides. Sure. I'm not saying that Unix signals is the only sensible thing but that I don't know how a good alternative could look like. > 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 is used for broken pipes because C doesn't have exceptions (and sloppy programs might not check the error status of write()). For me an error return is enough, in my language it's mapped to an exception anyway. > it's wrong for socket discovery, What is this? > it's wrong for inter-thread communication. Yes. But "this mechanism is not suitable for that purpose" doesn't imply "this mechanism is brain damaged". -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .