1. Is there any mechanism to remove a process from the run queue and later put it back without notifying the process that this has occurred? Sigstop and sigcont don't suffice, because they notify the process. And if there is such a mechanism, then is there a way to tell the kernel's scheduler to use it instead of sigstop and sigcont for a particular process, so that the process thinks that it runs without ever being preempted by the scheduler?
2. The man page for kill says that "kill -s sigstop 1000" should send sigstop to process 1000, but instead it outputs the error message "kill: bad signal". I tried "kill -s stop 1000", "kill -sigstop 1000", and "kill -stop 1000" with the same result. Only "kill -23 1000" actually works. Is the man page wrong, or is kill broken, or am I missing something obvious? 3. It appears that sigkill unschedules a process without notification and then destroys it, but it appears that there's no signal to unschedule a process without notification and then dump its core before destroying the process. Is this possible? Sigquit and sigabrt don't suffice because they notify the process first (thus giving the process the opportunity to change its state prior to dumping core) and give it the option to ignore the signal (thus not dumping core at all). 4. Is it possible to dump a process's core (without notifying the process when this happens) but not kill the process? This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
