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

> On 20/12/2007, Tom Phoenix <rootbeer at redcat.com> wrote:
> > On 12/20/07, Igor Stasenko <siguctua at 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.



-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071221/03eafedf/attachment.htm