On 21/12/2007, Louis LaBrunda <Lou at keystone-software.com> wrote:
> Hi,
>
> I'm new to squeak, so I'm not sure how all this works in Squeak but I have had
> occasion to look into how Process, ProcessorScheduler, Semaphore and Delay work
> in VA Smalltalk.  They all work closely together.  ProcessorScheduler handles
> the scheduling, suspending and resuming of Processes.
>
> The scheduler keeps a list (an array of queues, one for each priority level) of
> ready to run processes.  A wait on a Semaphore or Delay removes (via #suspend) a
> process from the ready to run list and keeps track when to add it back (via
> #resume).  In Squeak, Delay uses a Semaphore, so these classes are even more
> closely tied than in VAST.
>
> >> The #resume should be no-op if process was not suspended by previous
> >> call of #suspend.
> >> But currently, by sending #resume to process which waiting for signal
> >> causing it to continue running as if signal raised.
> >
> >That is a bug and should be fixed.
>
> In VAST resuming a terminated process is a no-op in Squeak it looks like it is
> an error.  In both, resuming a suspended process is a no-op, I don't see the bug
> here.  Again, waiting on a Semaphore or Delay does a #suspend, so sending
> #resume to a process waiting on a Semaphore or Delay will bring the process out
> of its suspended state.  Changing this behavior would be a big deal and I don't
> see a good reason for the change.
>
> I think that in Squeak #isSuspended (maybe not the best name) will tell you if a
> process is waiting on a Semaphore or a Delay, if you don't want it to resume
> prematurely, don't send it a #resume.
>
That's the is point that in squeak processes which waiting for
semaphore returning false on #isSuspended.
And i think it's correct, because a 'waiting' is not the same as being
suspended.
You may think as if its doing:

[ semaphore isSignaled ] whileFalse: [].

So, it's should be considered as running.
And if we going further on that, then sending #resume on process which
waits should be no-op, because its _already_ running.

But, if we mark process  which waiting on semaphore as suspended, then
, obviously it should answer true on #isSuspended (but it's not in
current squeak).
And btw, this is bad idea - because you will lose real control on when
this process will be allowed to awake. It can awake at any time when
semaphore is signaled. Ans sometimes, this can be not really what you
want!

So, i think we should fix the #resume  and never assume that process
which waiting on semaphore are suspended. 'Waiting' and 'suspending'
should be different, IMHO!


-- 
Best regards,
Igor Stasenko AKA sig.