problem with removing a dead thread from system

I have a problem with threads.

I do the following:

process := [ <recursive method> <clean-up ] fork

I run this inside an app window and it takes many hours to run.
Inside the same app I can stop the process at any time by using a flag
to let the recursive method complete and then do the clean-up followed
by process := nil

This works ok.

But when I try to run the above again from fresh within the same app
the old process is still there (status dead) and prevents a fresh run.

Inspecting Process allInstances confirms this.

It seems that even though the old spent process is dead, it still
exists in the system so preventing an identically named process from
running. The only thing that removes it is to close my app and
re-open.

I'm desperate for help on this as I've pretty nigh on exhausted
different avenues.

Regards, John Trinder

John,

> It seems that even though the old spent process is dead, it still
> exists in the system so preventing an identically named process from
> running. The only thing that removes it is to close my app and
> re-open.

I'm skeptical about the name collision theory.  Try the following in a
workspace:

     Processor forkMainIfMain.
     Process allInstances collect:[ :each | each name ].

I get:

  #('Timing' 'Undertaker' 'Finalizer' 'Main' 'Idler' 'Main')

so AFAIK, there's no problem scheduling multiple threads with the same name.


> I'm desperate for help on this as I've pretty nigh on exhausted
> different avenues.

The fact that the Process instance is hanging around probably means that
there is a reference to it preventing its being gc'd.  You can try tracing
references back to the culprit, or (often easier) think about any places
(globals, instance or class variables) where you might be holding it and nil
them.  Also, it could simply be a workspace variable - high on my (very
short) list of things that I wish were not present/supported in Dolphin.
Right click in the workspace, and look for Variables... - deleting the
offender, or simply setting it to nil might help.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:ai9bs7$12cgab$[hidden email]...
> ...
> The fact that the Process instance is hanging around probably means that
> there is a reference to it preventing its being gc'd.  You can try tracing
> references back to the culprit, or (often easier) think about any places
> (globals, instance or class variables) where you might be holding it and
nil
> them.  Also, it could simply be a workspace variable - high on my (very
> short) list of things that I wish were not present/supported in Dolphin.
> Right click in the workspace, and look for Variables... - deleting the
> offender, or simply setting it to nil might help.

I'll just add to what Bill says by suggesting the use of the
ReferenceFinder. First run 'Process allInstances' to find your process, but
preferably don't assign it to another variable, instead work out the index
it is at in the instance list. It will not move (at least not unless you
save the image), then inspect the result of:

ReferenceFinder findAllPathsTo: (Process allInstances at: <the index you
found it>)

It will take a long time, but you can monitor progress on the transcript.

At the end of it you will have a list of paths from global "roots" to your
process. One or other of these will be keeping the Process from being
collected.

Regards

Blair

"Bill Schwab" <[hidden email]> wrote in message news:<ai9bs7$12cgab$[hidden email]>...
Thanks for your help Bill.

I can confirm that name-clash isn't the problem nor known (to me)
references.
So I'm left with the fact that there is an unknown reference that only
disappears when I close the app that ran the thread.
You say "try tracing references back to the culprit".
This seems to be the right tack, but (excuse my lack of smalltalk
knowledge) how do I go about doing this.
Also, why can't I run a fresh thread - you can do that with Main?

Regards, John

John,

> I can confirm that name-clash isn't the problem nor known (to me)
> references.
> So I'm left with the fact that there is an unknown reference that only
> disappears when I close the app that ran the thread.
> You say "try tracing references back to the culprit".
> This seems to be the right tack, but (excuse my lack of smalltalk
> knowledge) how do I go about doing this.

It's not fun, but basically it involves inspecting the thread and then
choosing "Inspect references" from the context menu until you find the
culprit.  One complication is that the inspectors appear in the results.  It
would be nice to have a tool that did the tracing with weak references to
reduce the clutter.

Do you hold thread in an instance variable?  It sounds like that's the
problem.


> Also, why can't I run a fresh thread - you can do that with Main?

When you say it can't run, what happens?  Either Dolphin's Process Monitor
or the ProcessViewer in my goodies distribution will show you if it starts
and then deadlocks on something.  Is it perhaps waiting on a semaphore
that's not signalled or a mutex locked by the other thread (this latter one
seems unlikely because of the #dead status of the first thread).  Are you
perhaps trying to re-use a Delay?  They are not designed for that, or at
least they were not in D4 and earlier.

Which version of Dolphin are you using?

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:aibrf5$123ssr$[hidden email]... It
> would be nice to have a tool that did the tracing with weak references to
> reduce the clutter.

The best way to trace references is with the ReferenceFinder. This is a
utility class that can find all paths from a "root" (e.g. a global) to a
particular object, allowing one to see why it is being kept alive.  So in
this case:

First run 'Process allInstances' to find the process, but preferably don't
assign it to another variable, instead work out the index it is at in the
instance list. It will not move (at least not unless you save the image),
then inspect the result of:

    ReferenceFinder findAllPathsTo: (Process allInstances at: <the index you
found it>)

It will take a long time, but you can monitor progress on the transcript.

At the end of it you will have a list of paths from global "roots" to your
process. One or other of these will be keeping the Process from being
collected.

Regards

Blair

one

"John Trinder" <[hidden email]> wrote in message
news:[hidden email]...
> Also, why can't I run a fresh thread - you can do that with Main?

What exactly happens when you try to run it?

Blair

Bill,

Sorry to pick your brains needlessly.
On closer investigation of the Process instances in the system at
various times in the execution of my app, I found that my dead process
was actually being removed from the system correctly.
The problem was a logical error in my programming, which was buried
under considerable complexity.
Thanks to your advice in putting me on the right tack though. I was
able to realize that there had to have been an error on my behalf to
account for the problem, I then went on and located it.

Many thanks for your assistance.

Regards, John