none
IObservable and SynchronizationContext

    Question

  • How does Rx interact with SynchronizationContext? It appears that operators automatically use SyncContext when synchronization is required, but the Reflector code is not the easiest to read. ;)

    Could someone briefly describe the overall design of Rx with regards to SyncContext? e.g., Observable.Context and System.Threading.SynchronizationContexts.

    Thanks,
           -Steve


    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ

    Microsoft Certified Professional Developer
    Thursday, November 19, 2009 3:04 PM

Answers

All replies

  • Hi Steve,

    Great request, I'll need some time to write a good description. I'll post to my blog (http://blogs.msdn.com/jeffva/) later today.

    Thanks,


    Jeffrey
    Thursday, November 19, 2009 3:45 PM
  • Observable.Context is global.

    To me, this is a somewhat troubling point. First, does it make sense to synchronize all Rx sequences with a single SyncContext? Second, is every Rx operator implicitly synchronized and therefore running on a single thread?

    My first question has more to do with multiple, independent Rx sequences, so a child thread (such as an ActionThread from the Nito.Async library: http://nitoasync.codeplex.com/) could be responding to some Rx sequences while a main thread (GUI thread) could be responding to other Rx sequences. This would require different scoping for SyncContext - something more like what Tasks provides: http://blogs.msdn.com/pfxteam/archive/2009/09/22/9898090.aspx. However, one could argue that with a complete set of operators, multiple independent Rx sequences would not ever be necessary (leaving out "shared host" situations like ASP.NET, AutoCAD, and SQL Server).

    My second question has more to do with enabling parallelism. For the next release of Nito.Async.Sockets, I want to expose an Rx interface for sockets. Part of this will probably be a Read stream representing bytes read from a connected socket. Then an Rx operator will be used to transform the bytes read into messages read (for more information about the difference, see http://nitoprograms.blogspot.com/2009/04/message-framing.html). It would be best if this operator would run on a ThreadPool thread, since its output is entirely determined by its input. Other operators could be linked in as well (deserialization, keepalive timeouts), and only the final stream would need to be synchronized.

    Looking forward to Jeff's blog post. :)

           -Steve


    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ

    Microsoft Certified Professional Developer
    Friday, November 20, 2009 11:53 AM
  • Sorry was extremely busy yesterday with some future Rx stuff. Will try to post about this subject soon...

    Jeffrey
    Friday, November 20, 2009 4:12 PM
  • My blog post on SynchronizationContexts is up (on the RxTeam blog instead of my personal blog by accident): http://blogs.msdn.com/rxteam/archive/2009/11/21/observable-context-observable-subscribeon-and-observable-observeon.aspx

    • Proposed as answer by Richard Hein Saturday, November 21, 2009 2:45 AM
    • Marked as answer by Stephen ClearyMVP Saturday, November 21, 2009 11:14 AM
    Saturday, November 21, 2009 2:19 AM
  • very interesting post, it explains alot :)
    however i share stephens concerns that Observable.Context is static.. what if someone changes the context at some other point in the program? i might be mistaken but doesnt the operators look at the static context every time? that would mean that an iobservable posting on the ui thread would work fine until some other part of the code switches the default context to something else..

    perhaps another option would be o have Observables inheirit the context that their parents have? or perhaps some sort of factory solution like with tasks..
    i dont know, but it somehow feels wrong to have the default context as a global variable :)

    Monday, November 23, 2009 8:59 AM
  • Hi Jeffrey & Rx Team,

    Does the Rx library include somewhere an equivalent to Subject<T> that doesn't mess with SynchronizationContexts, and instead just passes notifications through on the calling thread?  I have use for a "dumb" ISubject<T> but don't want to duplicate effort writing and testing my own if one already exists.

    Thanks for your time.

    -Gabriel
    Monday, November 23, 2009 10:07 AM
  • Rx will soon be changing how it handles SynchronizationContexts quite a bit based both on the feedback (yours included) as well our  own experience.  I think you will like what you find.  Let us know when that happens.
    Wednesday, November 25, 2009 12:14 AM
  • That is awesome news.  If you guys can nail the semantics of that, I think Rx will be unstoppable. :)
    Wednesday, November 25, 2009 2:22 AM