On Dec 21, 2007 8:09 AM, Igor Stasenko <siguctua@gmail.com> wrote:

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 code looks wrong.

I think what you want is:

sema := Semaphore new.
proc := [ sema wait. Transcript show: 'Oopsie'. ] fork.
proc suspend.
sema signal.
proc resume.

I can't try this code at the moment - I don't have Squeak nearby.

Generally, I'd rarely use Process>>suspend in my code. Semaphores provide the behaviour that you want; a Semaphore is a linked list of waiting processes. When you call #wait on a semaphore, your process gets added to the list. When you call #signal, the process at one of the ends of the list (FIFO? LIFO? Can't remember) gets resumed. The effect of #suspend and #resume should have no effect on the signalled/waiting state of a Process.

In the Launcher example that you give, it would be okay to use #suspend and #resume, but there shouldn't be anything else in the image which is trying to suspend or resume those processes.

Gulik.