On 20/12/2007, Tom Phoenix <rootbeer at redcat.com> wrote:
> 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.
>
Or illustrates that system classes having glitches?

> > 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?

Because process is object and you allowed to send anything you want :)
And its should be an object's responsibility for it's own behavior,
not the sender's.

And if you want to have processes which not able to suspend/resume,
then you make it without these methods or make a subclass with methods
doing no-op or throwing an error in this methods. But in current
design it placing too much responsibility on caller rather than on
implementation.

And all of this is against spirit of ST. Why i should learn details
about Semaphore when i using Process? Why my code should contain
special conditions based on process/semaphore specifics, rather than
simply call what i want to be called?

>
> 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.
>
Suspend count is much simpler.  :)

> Good luck with it!
>
> --Tom Phoenix
>

-- 
Best regards,
Igor Stasenko AKA sig.