resumes & suspends

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

resumes & suspends

Hwa Jong Oh
Do you think this the following methods useful(maybe harmful)?

I made them because #resume #suspend should be used with care of not to be
called more than once, which is unlike SuspendThread() ResumeThread() of
MFC.

Process>>suspendIfNot

 self state = #suspended
  ifFalse: [self suspend]


Process>>resumeIfNot

 self state = #suspended
  ifTrue: [self resume]

Hwa Jong Oh


Reply | Threaded
Open this post in threaded view
|

Re: resumes & suspends

Blair McGlashan
"Hwa Jong Oh" <[hidden email]> wrote in message
news:8vu22d$5afp8$[hidden email]...

> Do you think this the following methods useful(maybe harmful)?
>
> I made them because #resume #suspend should be used with care of not to be
> called more than once, which is unlike SuspendThread() ResumeThread() of
> MFC.
>
> Process>>suspendIfNot
>...
> Process>>resumeIfNot
>...

I think that two existing methods may already meet your needs:
Process>>suspendUnconditionally and Process>>resumeUnconditionally.

BTW: Be careful with suspending and resuming processes. Just as with
SuspendThread() you might suspend a Process in the middle of a critical
section (Mutex) and thus block other Processes. You should really only
suspend processes in a known state, and the best way to guarantee that is
for processes to only suspend themselves (i.e. by sending #suspendActive to
Processor). Bear in mind also that when a process is suspended, if there are
not other references to it, it will be garbage collected.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: resumes & suspends

Hwa Jong Oh
Blair,

> I think that two existing methods may already meet your needs:
> Process>>suspendUnconditionally and Process>>resumeUnconditionally.

Before creation of my methods #resumeIfNot #suspendIfNot, I had already
tested those xxxUnconditionally methods to see if methods i wanted already
exist. xxxxUnconditionally were found and they had been tested. Not proper
was the decision after the test. The test was like(I'm not sure that I
remeber them correctly. Sorry)

p := [[]repeat] forkBack. "#forkBack is fork: (Processor
userBackgroundPriority) in short"
p state. "check the state of process" "ready as i remember"
p suspendUnconditionally.
p state. "check the state of process" "suspended as i remember"
p suspednUncondionally. "BEEP error!"

> BTW: Be careful with suspending and resuming processes. Just as with
> SuspendThread() you might suspend a Process in the middle of a critical
> section (Mutex) and thus block other Processes. You should really only
> suspend processes in a known state, and the best way to guarantee that is
> for processes to only suspend themselves (i.e. by sending #suspendActive
to
> Processor). Bear in mind also that when a process is suspended, if there
are
> not other references to it, it will be garbage collected.

Thank you for your kind additional tips! You must be anxious about DeadLocks
but I have rarely ever
had trouble of DeadLocks with ResumeThread(), SuspendThread(). Maybe I have
been lucky, or I have
ever had a chance to face complicated multiprocess control pattern.
I'm eager to learn more about your techniques of "self suspend only
multiprocess control".

It will be nice if someone give a fine lectures on multi processing in a
wiki or Edu.Cent.

Thank you again for your kindness
Hwa Jong Oh