On 12/20/07, Igor Stasenko <siguctua at 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