Well, in Unix it works like this:

If a process tries to use some contended or unavailable resource it is
taken off the CPU and moved into a wait queue for that resource.
While in a wait queue a process mask is put in place depending on the
queue.  The process mask may say certain signals are simply not
delivered at all, the process may receive the signals after it comes
off the wait queue (e.g. a suspend sent to a process waiting on IO) or
it may be applied while on the queue (e.g. kill/terminate sent to a
process waiting on a semaphore).

So from that point of view the wait queue has a part in the
responsibility of deciding how a process would handle a suspend.

What I plan to do at some point is move Squeak even more toward being
its own OS (e.g. more sophisticated process scheduling at talked about
in a previous thread, etc.).

On Dec 21, 2007 6:19 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
> 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.
>
>