opencog-dev team mailing list archive

[Linas Vepstas <linasvepstas@xxxxxxxxx>]

2009/3/20 Joel Pitt <joel.pitt@xxxxxxxxx>:
> On Sat, Mar 21, 2009 at 3:13 AM, Linas Vepstas <linasvepstas@xxxxxxxxx> wrote:
>>> (I've discover this is the source of some tests failing on buildbot
>>> and for random people ...
>>
>> well, technically speaking, checking for a null pointer is
>> the wrong thing to do. The tests should have checked for
>> undefined handle.
>
> The problem I have is that if I have a set Handles, and then during
> the life of Handle, some become invalid through removals (and not just
> the expected one, because removals can recursively remove others). I
> could probably hack around to avoid this, but I think it'd be a bigger
> problem, especially when things get multithreaded and distributed.

Well, but that's exactly the point. If some other thread
deletes an atom, then calling TLB::IsInvalidHandle() is
guaranteed to give you the correct answer.  By contrast,
some pointer to atom might be stale: it may be pointing
at some atom that no longer exists.

Perhaps you meant this:
(NULL == TLB::getAtom(hand))

Then that's OK,  since it is exactly identical to
TLB::IsInvalidHandle(hand)

... err, *should be identical*. After code review, I see
that its not, and  that is a bug.  Should I fix it? Do you
want to do this?

I also see that TLB.h still has traces of "non-real atom"
code in it. I presume its OK to remove this now?

--linas