On 20/12/2007, Tom Phoenix rootbeer@redcat.com wrote:
On 12/20/07, Igor Stasenko siguctua@gmail.com wrote:
This is essentially useful when you need to guarantee that process will stay suspended even if it's currently suspended waiting for semaphore signal.
Do you mean to say that your processes resume running before their semaphores are signaled?
Just try to run given code:
| sema proc | sema := Semaphore new. proc := [ sema critical: [ Transcript show: 'Oopsie' ] ] fork. Processor yield. proc suspend. proc resume.
This example illustrates, that suspend/resume having an issues, when using semaphores. Why caller needs to have specific knowledge about process (is it waits for semaphore or not) if he just simply wants to temporary suspend it and then resume?
If that's not it, what problem are you really trying to fix here? If you want to keep a process that's waiting for a signal from resuming execution when that signal is sent, you're interfering with signal handling, aren't you? That could cause serious troubles in the long run, and the long run might only be a few seconds.
No matter what is process doing. This is simply not an excuse. And of course, for people who want that, they are sure that they do what they need to do. Otherwise there will be no need in such discussion.
Most of the time, most users want most processes to run at full speed. It sounds like you're trying to change that, possibly idling the CPU; why?
Maybe you simply want to do some operation in a high-priority process, so as to keep lower-priority processes from interrupting key parts?
Cheers!
--Tom Phoenix