message from a Process?

Hi.

How can I receive a state transition report from a Process?

ready->dead
running->suspended

(trigger: #processStateChanded)

Hwa Jong Oh

Hwa Jong,

> How can I receive a state transition report from a Process?
>
> ready->dead

Usually for this kind of thing, I signal a semaphore from an ensured block,
something like the following:

   [
      [
         "Some interesting code goes here"

      ] ensure:[
         aSemaphore signal.
      ].
   ] fork.

Another thread will be waiting on the semaphore, and can then take
appropriate action.  In many cases, it's enough to do cleanup directly in
the ensured block.


> running->suspended

I've never felt the need to do this.  Unless you're writing a profiler (Ian,
that's your cue<g>), it seems unlikely that you'd need to know.  For more
typical applications, it's best to stay with the basic synchronization
mechanisms and let the process scheduler do as it wants.

Somehow I suspect I'm not being of much help though :)

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

Many thanks for your advice.

> > running->suspended
>
> I've never felt the need to do this.  Unless you're writing a profiler
(Ian,
> that's your cue<g>), it seems unlikely that you'd need to know.  For more
> typical applications, it's best to stay with the basic synchronization
> mechanisms and let the process scheduler do as it wants.

Your reply seems to imply that there is no direct way to get notification
from the state changing process.

I needed a presenter that can present(show & control) a process, thus I can
control my Algorithm object to stop or  go
or show it's working status. : ProcessPresenter.
(NOTE: Algorithm is a base class that supports iterative simulations for
historying, iteration counting, controlling.
It is currently supporting KMeansAlgorithm, ClassificationAlgorithm,
BackpropagationLearningRule, GeneticAlgorithm).
I couldn't be satisfied by the ProcessDialog which disables controlling of
other views when shown modal, or look untidy when shown
modaless. I'm considering your solution as a default one, and look around
for other possible ways.


> Somehow I suspect I'm not being of much help though :)

Your advice is always being a help.

Hwa Jong,

> Your reply seems to imply that there is no direct way to get notification
> from the state changing process.

That's my understanding, but, Ian and Blair might have more to say.


> I needed a presenter that can present(show & control) a process, thus I
can
> control my Algorithm object to stop or  go

You can do something like the following:

aThread := [
   [
      someObject someMessage whileTrue:[
         aSemaphore wait; signal.
      ].

   ] ensure:[ "Clean up" ]
] fork.

There are two opportunities to control the thread: (1) control the return
value the decides whether it continues to iterate; (2) send #wait to
aSempahore when you want the thread to stop.  The problem with this
semaphore trick is that you have to get the number of signals and waits
correct or the results might be disappointing.  You signal the semaphore
once to start the thread.  It consumes one signal (via #wait) and then
immediately puts it back via #signal.  When some other thread wants to stop
this one, all it has to do is send #wait to the semaphore.  Provided you
have the number of calls correct, the semaphore will be signaled so the
"controlling" thread will move past the #wait, and controlled thread wil
block the next time it reaches #wait.


> or show it's working status. : ProcessPresenter.
> (NOTE: Algorithm is a base class that supports iterative simulations for
> historying, iteration counting, controlling.
> It is currently supporting KMeansAlgorithm, ClassificationAlgorithm,
> BackpropagationLearningRule, GeneticAlgorithm).

My recommendation would be to build a little extra functionality into your
classes.  Since you built them for related jobs, you can add some kind of
common status reporting functionality w/o much trouble.

One caution: be careful about controlling list views from background
threads.  It's best to decide on the changes in the background and then use
#queueDeferredAction: to update the GUI.  Obvious comments about multiple
cooks spoiling the broth apply.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]