Smalltalk › Squeak › Squeak - Dev

Suspending/resuming processes

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Ron Teitelbaum

RE: Suspending/resuming processes

Hi All,

Let me try too. I model the world, and I put a stop light in front of a
car. Then I stop the world for a minute.

When I restart the world it shouldn't change the stop light in my world. It
should only restart the time.

A suspended process is stopping time in my world. The stop light is a
semaphore that is waiting in my code which is running in my world. Resuming
the process should not change anything that is waiting in that thread.
Starting the time should not change the stoplight. I could have two green
lights at one intersection and cars smashing up all over the place. It
could get very messy.

It's a bug.

Ron Teitelbaum

> -----Original Message-----
> From: Igor Stasenko
>
> Let me make it clear for the last time.
>
> Waiting is an _action_.
>
> And process allowed to perform any _actions_ if it's not suspended.
> If you suspend process, it should stop performing actions until it
> receive #resume.
>
> As another viewpoint, we can consider waiting for #resume as an action
> too.
> But since process can perform only single action at some point of
> time, it can't perform 'wait for resume' and 'wait for signal' in
> parallel.
>
> --
> Best regards,
> Igor Stasenko AKA sig.

Jason Johnson-5

Re: Suspending/resuming processes

In reply to this post by Igor Stasenko

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 <[hidden email]> wrote:

>
> On 21/12/2007, Louis LaBrunda <[hidden email]> 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.
>
>