Failing Test Case: Delayed Lifetime deinit deadlocking sendLock. (#137)

[andersio]

Related issue: #135

Cause

1. A strong release atomically drops the refCount to 0. But deinitialization does not start right away.
2. A weak retain - the binding's observer closure in this case - manages to increment the refCount before the strong release flags the object as deallocating.
3. The deinitialization is thus delayed until exiting the scope of the observer closure, i.e. within the sendLock.

What's affected?

Everything in the following pattern:

signal
    .take(during: object.lifetime)
    .observeValues { [weak object] _ in }

Note

The test case would not fail in a uniprocessor environment.

Possible Solution

Allowing completed to be recursively sent like interrupted seems the only way, since:

1. We have no autoreleasepool for Swift objects.
2. The order cannot be controlled.

[andersio]

NSRecursiveLock unfortunately seems the easiest solution to this race condition. Handling completed like interrupted is like opening Pandora's box, racing with Swift's deallocation routines concurrently, and having malloc broken or polluted somehow.

Got something up... Seemed like it was suffering from corrupted state before...