Unserialized and Reentrant Signals
#797
Conversation
andersio
force-pushed
the
unserialized-pipes
branch
2 times, most recently
from
7e1422a
to
924a55b
Compare
andersio
force-pushed
the
unserialized-pipes
branch
from
924a55b
to
f0ac694
Compare
There was a problem hiding this comment.
I think this will be a nice improvement, thanks!
I'd like to take a deeper look at the code, but for now I did a quick scan for API naming. Wondering what you think about using the term unserialized instead of non-serializing, which reads awkwardly to me.
The terms introduced to our public API here a subtle, so I also left a suggestion that we could perhaps document them in a glossary of sorts to get a very clear definition that we can point to for decisions about where one makes more sense than the other. I'd also like to have a think about whether there's a better term to use than "unserialized".
| @@ -200,6 +200,51 @@ class SignalSpec: QuickSpec { | |||
| } | |||
| } | |||
|
|
|||
| describe("reentrant") { | |||
| #if arch(x86_64) && canImport(Darwin) | |||
There was a problem hiding this comment.
What's the reason for restricting this text to x86?
There was a problem hiding this comment.
Catching deadlock by intercepting signals is supported only in iOS simulators.
https://github.com/mattgallagher/CwlPreconditionTesting#cwlpreconditiontesting
A Mach exception handler, written in Swift and Objective-C, that allows EXC_BAD_INSTRUCTION (as raised by Swift's assertionFailure/preconditionFailure/fatalError) to be caught and tested.
NOTE: the iOS code runs in the simulator only. It is for logic testing and cannot be deployed to the device due to the Mach exception API being private on iOS.
There was a problem hiding this comment.
It is more a question for Nimble/CwlPreconditionSignal. If they support catching signals on arm64/M1, we can lift this.
andersio
changed the title
SignalsSignals
|
Any update on when this might get merged @andersio ? |
Signalnow offers an unserialized variant and a reentrant variant for advanced users. (Unserialized and ReentrantSignals #797)These new primitives would be adopted by ReactiveCocoa UIKit bindings to improve interoperability with RAC Loop, to tackle some legitimate recursive delivery scenarios (e.g. around first responder management), and also to reduce fine-grained locking across ReactiveSwift and ReactiveCocoa.
Note that the default behavior of
Signalhas not been changed — event serialization remains the default behavior.MutablePropertyis also not gonna be reentrant, because there is no sane reentrancy model that supports access to the current value and multicasting while being compliant to the Property contract.Fine-grained locking has been scaled down across Signal, SignalProducer and Property. (Unserialized and Reentrant
Signals #797)Observers are naturally inheriting mutual exclusion from upstream, because the upstream has to serialize the events to be compliant to the Event contract. So for most transformations involving only one event stream (Signal/Producer), the locks for serializing events are redundant. This is also the same premise that RAS 2.0 producer optimizations are built upon.
This similarly applies to Properties — both the read-only and the mutable versions have their own locks for mutual exclusion. So for them, the only value which the default event serialization in
Signal/SignalProducerbrings is wasting CPU time.Checklist