[squeak-dev] Pointer finder and processes

Eliot Miranda eliot.miranda at gmail.com
Thu Jan 12 18:30:58 UTC 2012


On Thu, Jan 12, 2012 at 10:23 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 12.01.2012, at 16:59, Bert Freudenberg wrote:
>
> > On 12.01.2012, at 15:53, Levente Uzonyi wrote:
> >
> >> On Tue, 10 Jan 2012, Bert Freudenberg wrote:
> >>
> >>> On Mon, 9 Jan 2012, Bert Freudenberg wrote:
> >>>> It's more important to be correct than to be fast - and I agree
> finding pointers is its main purpose, so your fix looks like an improvement.
> >>>
> >>>
> >>> Speaking of correctness: the pointer finder does not find an object
> that is held only by a process. Can we fix this?
> >>
> >> Can provide an example?
> >>
> >>
> >> Levente
> >
> >
> > | object |
> > object := {0}.
> > [
> >       | objRef |
> >       objRef := object.
> >       [
> >               objRef at: 1 put: (objRef at: 1) + 1.
> >               Transcript show: objRef first; cr.
> >               (Delay forSeconds: 1) wait.
> >       ] repeat.
> > ] forkNamed: 'Ref Test'.
> > object explorePointers.
> > object := nil.
> >
> > Initially, the explorer will find two objects pointing to the array -
> one is from the outer closure of the doIt, the other is the PointerExplorer
> itself. If you then toggle the array in the explorer, only one reference
> remains, from the explorer.
> >
> > Use the process browser to kill the process. Or before that, try to find
> references to the process itself from the browser's "inspect pointers"
> item. It seems to be held by a Semaphore, but nothing appears to hold the
> Semaphore.
> >
> > - Bert -
>
>
> Okay, false alarm, I understand now what's going on.
>
> The pointer finder works fine if I increase the time of the delay. The
> problem is that "Delay forSeconds: 1" creates a semaphore that holds onto
> the process, but it's gone after each second. Classical race condition - by
> the time the pointer finder is looking for the reference, it is already
> obsolete.
>
> This is even worse in my original problem which had a process polling 50
> times per second. Very hard to catch that.
>
> A workaround would be to run the pointer finder on a very high priority
> level ...
>

I doubt this will work.  The system won;t be responsive while something as
compute-intensive as the pointer finder runs if it does so at high
priority.  What if one took a snapshot of the runnable processes at
high-priority, at the start of searching for pointers?


>
> - Bert -
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120112/9149d7e0/attachment.htm


More information about the Squeak-dev mailing list