Re: Missing in sigaction
Re: Missing in sigaction
- Subject: Re: Missing in sigaction
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 28 Mar 2012 12:42:52 -0700
> 1/10th of a second is the maximum amount of time each thread is given
> to execute before the kernel preempts the thread, to allow another
> thread (or process) to execute. It's heavily ingrained in all
> Unix-based systems, a somewhat arbitrary decision made in the 1960s by
> Dennis Ritchie, the father of Unix. There have been attempts by
> others to modify that value, with results that caused performance to
> suffer, and the takeaway is that nobody has tried to modify the
> maximum timeslot since.
That's not true. Many systems (Linux, BSDs, etc) use a variety of other intervals - 100Hz, 250Hz, 1kHz, 4kHz, etc. It's often tuneable. There are sysctls etc for retrieving it - you should never hard-code an assumption.
It's also not a maximum, or strictly speaking a minimum. In the absence of contention (and blocking, obviously) a thread will remain on a core indefinitely. It may also be interrupted sooner than this designated interval for various high-priority threads. It's really only meant to say "for N contending threads with equal priority, give them each roughly X much time per N*X time period". Even that is arguable.
> When you wait in a signal handler longer than
> the maximum length of a context switch, other processes (and not other
> threads in the same process) will get multiple timeslots, but the
> process in which a signal handler sleeps will be stuck, unable to do
> anything else, because _nothing_ in that process other than other
> signal handlers (if not blocked) can be invoked while that signal
> handler is still running.
Also not true, as was pointed out.
I'm also not sure it makes sense to to even consider the scheduler interval. It's kind of an archaic concept. There's also no guarantee that you'll receive signals promptly, or that it's at the start of a quantum. There's no guarantee that you won't be signalled, put onto the signal stack, but then pre-empted immediately to another thread before you actual run the first instruction of your signal handler.
If there were bugs in signal handling, pre-emption would be a likely place for them, but they would be just that - bugs. Any assertion that you somehow have to avoid pre-emption in a signal handler is just bizarre in its impossibility.
None of this is to say that you should sit around signal handlers for a long time - there are many reasons not to, including the fact that you're interrupting your own code, potentially on the main thread, so you've no idea what could be timing out in the meantime. But you should be able to, technically, if you choose.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden