On Tue, 2005-12-27 at 06:55, Matty wrote: > On Tue, 27 Dec 2005, Andrew wrote: > > > 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? > > I'm not sure what you are trying to do here. A thread (not process) is told to remove itself from a dispq to run. While running, the thread may be preempted, exit, sleep, or stop. In all cases, the running thread is told to take some action and, at some point, does so.
> > 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? > > Do you mean "kill -s STOP 1000"??? > > 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). > > Hmm. You want a signal that causes core dump and exit which can not be caught or ignored... Not that I can think of. > > 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 > > Take a look at gcore and mdb. > > > _______________________________________________ > > opensolaris-code mailing list > > [email protected] > > https://opensolaris.org:444/mailman/listinfo/opensolaris-code > > > > -- > UNIX Administrator > http://daemons.net/~matty > _______________________________________________ > opensolaris-code mailing list > [email protected] > https://opensolaris.org:444/mailman/listinfo/opensolaris-code _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
