On 12/20/07, Igor Stasenko siguctua@gmail.com wrote:
| 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.
Well, either that or it illustrates that system classes can be misused. But beauty is in the eye of the beholder.
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?
Turn that around: Why should a caller without specific knowledge about a process (i.e., whether it may be waiting for a critical signal) be allowed to resume it?
If you want to suspend and resume _all_ other processes, though, that's the same thing as simply running a higher priority process for a while, isn't it?
But it sounds as if you really want to do this. If you're hoping that your changes will be useful outside your own image, I recommend that you don't change #resume or other key messages. I like Randal's suggestion of #countableSuspend, but there are other possibilities. If the resume would happen in the same block as the suspend, you could make it so your code would look something like this:
proc whileSuspended: [ "Whatever you need to do while it's suspended" ]. "The proc is back to its original run/suspended state now"
If you need to resume from a different block than it was suspended in, things get trickier. One idea would be to have a message with a better name than #resumableSuspend, which would return, let's say, an object of type ResumableProcess. You send that object #resume when you're ready, and it handles the other end of getting the process back the way you want it to be.
Good luck with it!
--Tom Phoenix