Subj : Re: How to manage time-slicing in Pthreads programs? To : comp.programming.threads From : David Schwartz Date : Mon Feb 21 2005 01:26 am "Marcin 'Qrczak' Kowalczyk" wrote in message news:87d5uue0n1.fsf@qrnik.zagroda... > "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. Right, sometimes you want to interrupt system calls. I didn't say that the problem was that it allows you to interrupt system calls, I said that the problem is that you have to deal with the interruption of system calls. And you can't just mask the signal, because you don't know what affect that will have on other code. > (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.) I think you're starting out wrong. By doing that, you get reduced concurrency for no reason. It's data that needs to be protected, not code. >> 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. That's fine if you have complete control over every piece of code. > 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. Exactly. It requires a coordination layer that all libraries must access, and there is no standard for one. The library could have provided one or the kernel could have, but neither has. >>> 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. A good alternative could look like UNIX signals with a coordination layer to prevent libraries and modules from stepping on each others toes. >> 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. The problem is, because sloppy programs might do something wrong, every program has to go through annoyance. I don't have a problem with asynchronous interruption as a default, I have a probem with it as the preferred mode. >> it's wrong for socket discovery, > > What is this? Determining which sockets are ready for I/O. Bluntly, signals are wrong for asynchronous I/O, period. Windows got this right with I/O completion ports. >> 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". Agreed, in principle. And the solution is trivial in principle, a coordination layer that all libraries talk to. The problem is, this solution does not exist in UNIX and it does in Windows. This is one area where Windows got it right and Unix got it wrong. The kernel provides adequate facilities to get it right if all user libraries talked to some coordination library that distributed the signals. The problem is that this coordination layer does not exist and would not work unless all code used it. DS .