[CC1.73/CC1.74] Random crash after block update

VERSION:
CC1.73/CC1.74
DESCRIPTION:
"java.lang.RuntimeException: You are not attached to this Computer:" (full stacktrace) is thrown when running simple program:

while true do peripheral.call("left", "testAttached") sleep(0) end

against test peripheral with single method:

return new Object[] { computer.getAttachmentName() };

(full peripheral code)
while spamming computer with rapid block updates (like redstone signal changes).

Note 1: crash seems to be easier to reproduce in SMP
Note 2: peripheral is not cached in any way, used provider can be seen here
EXPECTED RESULT:
This method should never fail, unless peripheral instance is somehow cached and used after block update, when new instance is generated.

I'd guess the issue is that when attaching the peripheral it uses the provider and when detaching it uses the provider, and so has two separate peripherals. Consequently when it tries to detach the peripheral it is detaching isn't attached (because it is a new instance) and so crashes.

A way to get around this would be to pass the coordinates and world instance to your peripheral, and override the equals(IPeripheral) method to check if the coordinates and world are the same.

I would guess that problem is caused by race condition between thread that invalidates associated IComputerAccess during neighbour update (stacktrace suggests it's main thread) and Lua thread that calls peripheral method with same IComputerAccess instance.
But that seems to be already heavily synchronized, so it's very possible that my guess is not correct (though it would explain non-deterministic behaviour).

Implementing 'equals' in different way (from 'same object' to 'wrapper for same position/block/TE') will of course limit number of peripheral updates, but may just hide underlying problem. Also, if this is actually expected from this method, it would be nice to have some information about this in Javadocs.

Yes, I think the equals function is the issue here. It would be extremely helpful to have documentation on it. I don't think "same object" is what it is meant for. If your peripheral doesn't change over time, I think the position/block/TE check may be more what it's intended for. You'll definitely see a decrease in superfluous attach/detach events, which the built-in peripherals do not exhibit.

I can't comment as to the possibility of a race condition, as I haven't looked into the guts of that side of things very deeply.