Subject.toSerialized

[benjchristensen]

Adds toSerialized as discussed in #1748

[zsxwing]

Could you change SerializedSubject to an interface, and change current SerializedSubject class to a DefaultSerializedSubject, like @samuelgruetter said in #1748 (comment)? So that a custom SerializedSubject does not need to extend the default implementation. I think it will be friendlier to extend.

[benjchristensen]

Why would we want a custom SerializedSubject? The point of SerializedSubject IS the implementation.

[benjchristensen]

Also, this is matching the pattern of SerializedObserver and SerializedSubscriber.

Each of these are "serialized" implementations of the interface they implement.

[samuelgruetter]

I think the question is the following: Is there only one possible reasonable implementation of SerializedSubject? If yes, there's no need for an interface, if no, an interface might be a good idea.
I don't have enough experience to answer this question.

[benjchristensen]

There are really only 3 ways to approach this that I'm aware of:

• Using blocking synchronization. We are trying to avoid that. We used to have SynchronizedObserver and replaced it with SerializedObserver.
• Using queues and thread-stealing to push through. This is the model SerializedObserver and SerializedSubject use.
• Using an MPSC queue with a separate thread to drain (standard producer/consumer). We don't want to add extra concurrency so are avoiding that. If an extra thread is wanted then observeOn is the answer.

Thus, there is really only one approach we want for this, and that is the SerializedObserver approach, hence SerializedSubject, which is an implementation of Subject that adds the Serialized capability.