[vwnc] [bug][vw7.6]Process monitor tries to use identity hash to uniquely identify processes

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Baumann
> Sent: Tuesday, August 04, 2009 5:38 PM
> To: 'Martin McClure'
> Cc: VWNC
> Subject: Re: [vwnc] [bug][vw7.6]Process monitor tries to use identity hash to uniquely identify
> processes
>
> Martin,
>
> Understood, combining the hashes only cuts odds of collision in half. That is why I also showed the
> method that answers interruptProtect to entirely avoid hash collision issues. I showed an existing
> attribute so the general idea is clear and simple. Process can be given a durable identifier that is
> simply an assigned object that is accessed by way of a method called #processIdentifier.
>
> The slow WeakArray cleanup that I mentioned is a non-issue if the collection is rebuilt with each
> query instead of maintained. Weakarray finalization delays affect enduring and maintained weakarray-
> based collections--the kind that we are most familiar with. Sorry to have mentioned that for this
> context.
>
> Your initial suggestion to use an index into the weak array was a good one. It looks like
> ProcessMonitorRecord.index was a half step toward that kind of implementation. ProcessMonitorRecord
> should be created with an index (the weekarray of all processes) and a position in that index.
>
> I'm glad you found this problem.
>
> Paul Baumann
>
> -----Original Message-----
> From: Martin McClure [mailto:[hidden email]]
> Sent: Tuesday, August 04, 2009 1:42 PM
> To: Paul Baumann
> Cc: VWNC
> Subject: Re: [vwnc] [bug][vw7.6]Process monitor tries to use identity hash to uniquely identify
> processes
> Importance: High
>
> Paul Baumann wrote:
> > I only spent about two minutes looking at it, but here is another trick to help uniquely identify a
> Process without a strong reference to the process...
> >
> > A way to indirectly reference the Process is through an identifier attribute; interruptProtect
> already looks suitable. Process.interruptProtect contains a Semaphore created unique to the process
> and that does not change. #processHash can return the bit shifted combination of both the process
> identityHash and the interruptProtect identityHash. Or, just gather and compare the objects from
> interruptProtect.
> >
>
> Hmm. Combining the identity hashes still doesn't create a unique identifier. It does reduce the
> probability of a collision. It's easy enough to be truly unique (see below) that one might as well be
> truly unique.
>
> Hanging on to the interruptProtect itself would be unique, but would keep the interruptProtect alive.
> That may not be a problem.
>
> > WeakArrays are slow to cleanup. I'd avoid them for process level stuff.
>
> Keeping a Process instance alive doesn't create any problems that I know of, AFAIK it's just another
> object unless the ProcessorScheduler is working with it. And you have to reference a Process somehow.
> The choices seem to be:
>
> * Do an #allInstances every time you need to access any Process, then search the results for the one
> you want. Finding the one you want is slightly tricky; comparing the interruptProtect would work.
> This would be fairly slow.
>
> * Keep a strong reference to each Process. This keeps the Process alive.
> The main disadvantage of this approach is that if you leave a ProcessMonitor open while many
> Processes are created and discarded, you'll accumulate dead Processes in your list and it will be
> harder to find the ones you're interested in.
>
> * Keep a weak reference to the Process. This is the current approach, which seems reasonable.
>
> * Keep an ephemeron reference to the Process. This has approximately the same advantages and
> disadvantages as the weak reference.
>
> With either weak or ephemeron, by using a weak-valued dictionary you can create whatever unique key
> you want. This could be as simple as an 'Object new' for each key, passed back and forth in the
> record.
>
> Regards,
>
> -Martin
>
>
> This message may contain confidential information and is intended for specific recipients unless
> explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this
> message, please delete it and notify the sender. This message may not represent the opinion of
> IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a
> contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is
> expected to provide safeguards from viruses and pursue alternate means of communication where privacy
> or a binding message is desired.
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc