Rx Issue Tracker Rss Feed

Closed Unassigned: MfcTimeFliesLikeAnArrow crashes in rx-a82ffb9a7f4cdfe27c1530a2c5635c2b751ad630.zip [39]

kirkshoop — Thu, 20 Jun 2013 01:42:22 GMT

Stack trace (always in __crtCloseThreadpoolTimer, right away or some time after running the app, VS2012 11.0.60315.01 Update 2 on Windows 8 Enterprise):

ntdll.dll!77940dd9() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77910e81() Unknown
ntdll.dll!778a75d2() Unknown
> MfcTimeFliesLikeAnArrow.exe!__crtCloseThreadpoolTimer(_TP_TIMER * pti) Line 556 C
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::DeleteAsyncTimerAndUnloadLibrary(_TP_TIMER * timer) Line 696 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::TimedSingleWaitBlock::destroyTimer(bool waitForOutstandingCallback) Line 454 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::TimedSingleWaitBlock::Satisfy(Concurrency::Context * * pContextOut, Concurrency::details::EventWaitNode * pNode) Line 484 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::EventWaitNode::Satisfy(Concurrency::Context * * pContextOut) Line 330 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::_Condition_variable::notify_one() Line 645 C++
MfcTimeFliesLikeAnArrow.exe!do_signal(_Cnd_internal_imp_t * * cond, int all) Line 68 C++
MfcTimeFliesLikeAnArrow.exe!_Cnd_signal(_Cnd_internal_imp_t * * cond) Line 83 C++
MfcTimeFliesLikeAnArrow.exe!std::_Cnd_signalX(_Cnd_internal_imp_t * * _Cnd) Line 108 C++
MfcTimeFliesLikeAnArrow.exe!std::condition_variable::notify_one() Line 50 C++
MfcTimeFliesLikeAnArrow.exe!rxcpp::EventLoopScheduler::Derecurser::EnsureThread(std::function<std::thread __cdecl(std::function<void __cdecl(void)>)> & factory, std::shared_ptr<rxcpp::Scheduler> owner, std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000> > > dueTime, std::function<rxcpp::Disposable __cdecl(std::shared_ptr<rxcpp::Scheduler>)> work) Line 401 C++

Comments: This is a bug in the concurrency runtime. A connect bug exists and has been marked as fixed. perhaps we will have to wait for an update. https://connect.microsoft.com/VisualStudio/feedback/details/762560/crash-in-runtime-library-msvcr110-dll#details

Commented Unassigned: MfcTimeFliesLikeAnArrow crashes in rx-a82ffb9a7f4cdfe27c1530a2c5635c2b751ad630.zip [39]

kirkshoop — Wed, 19 Jun 2013 16:35:06 GMT

Stack trace (always in __crtCloseThreadpoolTimer, right away or some time after running the app, VS2012 11.0.60315.01 Update 2 on Windows 8 Enterprise):

ntdll.dll!77940dd9() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77910e81() Unknown
ntdll.dll!778a75d2() Unknown
> MfcTimeFliesLikeAnArrow.exe!__crtCloseThreadpoolTimer(_TP_TIMER * pti) Line 556 C
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::DeleteAsyncTimerAndUnloadLibrary(_TP_TIMER * timer) Line 696 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::TimedSingleWaitBlock::destroyTimer(bool waitForOutstandingCallback) Line 454 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::TimedSingleWaitBlock::Satisfy(Concurrency::Context * * pContextOut, Concurrency::details::EventWaitNode * pNode) Line 484 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::EventWaitNode::Satisfy(Concurrency::Context * * pContextOut) Line 330 C++
MfcTimeFliesLikeAnArrow.exe!Concurrency::details::_Condition_variable::notify_one() Line 645 C++
MfcTimeFliesLikeAnArrow.exe!do_signal(_Cnd_internal_imp_t * * cond, int all) Line 68 C++
MfcTimeFliesLikeAnArrow.exe!_Cnd_signal(_Cnd_internal_imp_t * * cond) Line 83 C++
MfcTimeFliesLikeAnArrow.exe!std::_Cnd_signalX(_Cnd_internal_imp_t * * _Cnd) Line 108 C++
MfcTimeFliesLikeAnArrow.exe!std::condition_variable::notify_one() Line 50 C++
MfcTimeFliesLikeAnArrow.exe!rxcpp::EventLoopScheduler::Derecurser::EnsureThread(std::function<std::thread __cdecl(std::function<void __cdecl(void)>)> & factory, std::shared_ptr<rxcpp::Scheduler> owner, std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000> > > dueTime, std::function<rxcpp::Disposable __cdecl(std::shared_ptr<rxcpp::Scheduler>)> work) Line 401 C++

Comments: Thanks for the report. I can reproduce this. If I remove the observe_on then I cannot repro. That may be due to the WindowScheduler using PostMessage (which returns immediately) while without the WindowScheduler SetWindowPos is called (which ends up blocking in SendMessage). This would affect the timing of the EventScheduler thread management. I have not diagnosed the source of the problem yet though.

Created Unassigned: MfcTimeFliesLikeAnArrow crashes in rx-a82ffb9a7f4cdfe27c1530a2c5635c2b751ad630.zip [39]

Tonko — Wed, 19 Jun 2013 04:33:31 GMT

Closed Unassigned: OnNext should not be protected by try catch [38]

kirkshoop — Tue, 18 Jun 2013 04:45:24 GMT

For more detailed justification refer to the discussion at:
[Discussion link](https://rx.codeplex.com/discussions/430625)

Specifically, user code executing inside OnNext in CreatedObserver should not be protected by try/catch statements. To quote Rx Design guidelines:
> Note: do not protect calls to Subscribe, Dispose, OnNext, OnError and OnCompleted methods. These calls are on the edge of the monad. Calling the OnError method from these places will lead to unexpected behavior

The code for Rx operators should also be inspected to insure that user code exceptions can be clearly distinguished from Rx-operator-specific exceptions.

Comments: pushed changes

Commented Unassigned: OnNext should not be protected by try catch [38]

Tonko — Tue, 18 Jun 2013 03:39:19 GMT

Commented Unassigned: OnNext should not be protected by try catch [38]

kirkshoop — Mon, 17 Jun 2013 18:18:58 GMT

Created Unassigned: OnNext should not be protected by try catch [38]

Tonko — Mon, 17 Jun 2013 14:34:10 GMT

Created Unassigned: EventLoopScheduler SemaphoreFullException [37]

davedev — Thu, 13 Jun 2013 18:08:31 GMT

__EventLoopScheduler.Schedule__ may throw __SemaphoreFullException__. It appears that it may be due to a couple of race conditions in the __Run__ method:

1. Between the call to __Wait__ and acquisition of the lock.
2. Dequeueing expired items in a loop, without calling __Wait__ for each item.

Related discussion:
http://social.msdn.microsoft.com/Forums/en-US/rx/thread/223f2447-4cb9-47ce-be21-6fd0e5b45e30/?prof=required

Created Unassigned: Suggestion: AsObservablesWithPrecedence Operator [36]

davedev — Sun, 09 Jun 2013 15:57:18 GMT

Implement an overloaded operator named AsObservablesWithPrecedence that accepts an ISubject<T> and yields a list of observables with the specified subscription precedence, indicating the expected order of observations among the hot observables for a given notification.

Example implementation:
http://social.msdn.microsoft.com/Forums/en-US/rx/thread/a97a7e97-cb3d-4b42-afcb-8cb2c88c1778

Precedence is only guaranteed if all of the following are true:

1. The ISubject implementation natively ensures subscription precedence.
2. The ISubject's callers obey the Rx Grammar and serialize notifications; e.g., calls to OnNext never overlap.
3. Subscriptions to the ISubject are never made concurrently. (Though subscriptions to the generated observables can be made concurrently.)

Related discussion:
http://social.msdn.microsoft.com/Forums/en-US/rx/thread/ac721f91-4dbc-40b8-a2b2-19f00998239f

Commented Unassigned: Optimise ReplaySubject for specific cases [35]

LeeCampbell — Wed, 05 Jun 2013 22:00:59 GMT

Commented Issue: Help messages for obsolete APIs just refer the reader to Bing [18]

malayeri — Mon, 03 Jun 2013 23:31:32 GMT

There are a number of help messages for obsolete methods and properties which have help messages which end with "See http://go.microsoft.com/fwlink/?LinkID=260866 for more information." However, this URL resolves to http://www.bing.com which doesn't really help.

Can these messages be updated to refer to some more specific content, or removed?

Locations:

* Rx\NET\Source\System.Reactive.Core\Reactive\Internal\Constants.cs(11): public const string OBSOLETE_SCHEDULER_NEWTHREAD = OBSOLETE_REFACTORING + " Please add a reference to the System.Reactive.PlatformServices assembly for your target platform and use NewThreadScheduler.Default to obtain an instance of this scheduler type. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Core\Reactive\Internal\Constants.cs(12): public const string OBSOLETE_SCHEDULER_TASKPOOL = OBSOLETE_REFACTORING + " Please add a reference to the System.Reactive.PlatformServices assembly for your target platform and use TaskPoolScheduler.Default to obtain an instance of this scheduler type. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Core\Reactive\Internal\Constants.cs(13): public const string OBSOLETE_SCHEDULER_THREADPOOL = OBSOLETE_REFACTORING + " Consider using Scheduler.Default to obtain the platform's most appropriate pool-based scheduler. In order to access a specific pool-based scheduler, please add a reference to the System.Reactive.PlatformServices assembly for your target platform and use the appropriate scheduler in the System.Reactive.Concurrency namespace. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Core\Reactive\Internal\Constants.cs(15): public const string OBSOLETE_SCHEDULEREQUIRED = "This instance property is no longer supported. Use CurrentThreadScheduler.IsScheduleRequired instead. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Linq\Reactive\Internal\Constants.cs(14): public const string USE_ASYNC = "This blocking operation is no longer supported. Instead, use the async version in combination with C# and Visual Basic async/await support. In case you need a blocking operation, use Wait or convert the resulting observable sequence to a Task object and block. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Linq\Reactive\Internal\Constants.cs(15): public const string USE_TASK_FROMASYNCPATTERN = "This conversion is no longer supported. Replace use of the Begin/End asynchronous method pair with a new Task-based async method, and convert the result using ToObservable. If no Task-based async method is available, use Task.Factory.FromAsync to obtain a Task object. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Providers\Reactive\Internal\Constants.cs(14): public const string USE_ASYNC = "This blocking operation is no longer supported. Instead, use the async version in combination with C# and Visual Basic async/await support. In case you need a blocking operation, use Wait or convert the resulting observable sequence to a Task object and block. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Providers\Reactive\Internal\Constants.cs(15): public const string USE_TASK_FROMASYNCPATTERN = "This conversion is no longer supported. Replace use of the Begin/End asynchronous method pair with a new Task-based async method, and convert the result using ToObservable. If no Task-based async method is available, use Task.Factory.FromAsync to obtain a Task object. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
* Rx\NET\Source\System.Reactive.Windows.Threading\Reactive\Internal\Constants.cs(10): public const string OBSOLETE_INSTANCE_PROPERTY = "Use the Current property to retrieve the DispatcherScheduler instance for the current thread's Dispatcher object. See http://go.microsoft.com/fwlink/?LinkID=260866 for more information.";
Comments: Thanks for the detailed list--we know a lot of the links became broken when the MSDN documentation changed location. We are in the process of pulling in the MSDN docs into the git repository, so once that is complete, we can fix the FW links. Thanks for your patience!

Commented Issue: Observable.Timer() and Observable.Interval() throw exception if period == 0 [13]

davedev — Tue, 30 Apr 2013 21:46:41 GMT

Even though the documentation says period == 0 is supported:

```
/// <param name="period">Period to produce subsequent values. If this value is equal to TimeSpan.Zero, the timer will recur as fast as possible.</param>
```

Here is an example exception stack trace:
```
at System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.StartPeriodicTimer(Action action, TimeSpan period)
at System.Reactive.Concurrency.DefaultScheduler.SchedulePeriodic[TState](TState state, TimeSpan period, Func`2 action)
at System.Reactive.Concurrency.Scheduler.SchedulePeriodic_[TState](IScheduler scheduler, TState state, TimeSpan period, Func`2 action)
at System.Reactive.Concurrency.Scheduler.SchedulePeriodic[TState](IScheduler scheduler, TState state, TimeSpan period, Func`2 action)
at System.Reactive.Linq.Observαble.Timer.π.Run()
at System.Reactive.Linq.Observαble.Timer.Run(IObserver`1 observer, IDisposable cancel, Action`1 setSink)
(remainder elided)
```

The issue seems to be this code in __System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.StartPeriodicTimer(Action action, TimeSpan period)__:
```
//
// MSDN documentation states the following:
//
// "If period is zero (0) or negative one (-1) milliseconds and dueTime is positive, callback is invoked once;
// the periodic behavior of the timer is disabled, but can be re-enabled using the Change method."
//
if (period <= TimeSpan.Zero)
throw new ArgumentOutOfRangeException("period");
```

Even the comment seems to indicate Period==0 is allowed.
Comments: Pull request: https://rx.codeplex.com/SourceControl/network/forks/davedev/RxPeriodZero/contribution/4608

Commented Issue: BehaviorSubject.Current Property [8]

davedev — Tue, 30 Apr 2013 14:18:44 GMT

Please add a Current or Value property to BehaviorSubject<T> returning the instantaneous value so that it can be used more elegantly as a backing field for observable properties where the containing class may need to extract the current value imperatively, without using it in an asynchronous query. This would avoid the more costly and verbose recommended alternative to use .FirstAsync().Wait() as of Rx 2.0.

Open discussion:
http://social.msdn.microsoft.com/Forums/en-US/rx/thread/7b5b6982-4d03-4d44-a450-efebd5b2102a/
Comments: Pull request: https://rx.codeplex.com/SourceControl/network/forks/davedev/RxBehaviorSubjectValue/contribution/4602

Commented Unassigned: Optimise ReplaySubject for specific cases [35]

LeeCampbell — Wed, 17 Apr 2013 21:46:42 GMT

Currently the ReplaySubject is a very versatile class that can perform 5 major use cases
1. Replay-One. Caching and replaying the last value.
2. Replay-Many. (i.e. a value > 1)
3. Replay-Period. Cache data for a period of time for late subscribers
4. Replay by count and time. A combination of caching by count and period.
5. Replay-All. Cache and replay all values.

It seems to me that the most common usage* of Replay, "Replay(1)" incurs the cost of all the Scheduling and Buffering of the other implementations (Stopwatches, Queues, ImmutableLists of ScheduledObservers and the relevant checks).

My proposal is this: as the _bufferSize_ and _window_ are readonly values of a ReplaySubject, a specialization of the inner workings of the ReplaySubject can be loaded at construction time. For example if the new Replay(1) constructor was called then an internal implementation could be resolved that was specific and optimized for the behavior required by a Replay-one subject :
* Use ImmutableList<IObserver<T>> instead of ImmutableList<SchduedledObserver<T>>,
* no StopWatch,
* no internal Queue of cached values
* no Time and queue depth checks on every OnNext

For Replay(n) where n>1, then an implementation with an intenal queue could be used. Still this implementation would have no need for the ImmutableList<SchduedledObserver<T>>, StopWatch and the time checks on the OnNext call.

The two constructors that take a Window and a bufferSize+Window, could share an internal implemenation as I doubt there would be much perf difference between the two.

Finally the Reply-all behaviour where the parameterless constructor is used, could use the Replay-Many implementation passing Int.Max as a param, but this would still needlessly be calling the Trim method for each OnNext, so again is a candidate for specialization.

*In my opinion Replay(1) would be the most used operation of the ReplaySubject or the associated Replay extension method.
Comments: The short answer is "Yes, we are seeing perf issues". We switched out a quick modification of the ReplaySubject and noticed a large change in the number of allocations being made. In ReplaySubject the root of the allocations seems to come from private ImmutableList<ScheduledObserver<T>> _observers; Which in turn ScheduledObserver<T> has private readonly ConcurrentQueue<T> _queue = new ConcurrentQueue<T>(); which is excessively allocating arrays. I say excessively, but really I mean redundantly as we have no scheduling requirements, so dont need to cost of the ScheduledObserver<T>. I will try to create a test pack to reproduce our findings. w.r.t your proposed solution, thanks for the thought. However, I see this as a work around/hack where perhaps a far better implementation can be provided. I imagine as Rx gains in popularity (which it certainly seems to be doing), there will be an expectation that it performs optimally. I have seen that Rx has gathered quite a ground swell in the Capital Markets/Investment Banking industry where often data is provided at a pretty quick rate (100s of values per second). With a high tick rate and unnecessary allocations happening Garbage Collection can have an impact on performance. Essentially, I don't think that new users should have to learn a hack to get assumed performance, when the library could be optimized. Having said this, I have taken a fork of the repo and am working on a proposed fix. I am not expecting someone else to do this for me, but thought I would raise an "Issue" for it so it can be tracked. Lee

Commented Unassigned: Optimise ReplaySubject for specific cases [35]

davedev — Wed, 17 Apr 2013 20:42:03 GMT

Currently the ReplaySubject is a very versatile class that can perform 5 major use cases
1. Replay-One. Caching and replaying the last value.
2. Replay-Many. (i.e. a value > 1)
3. Replay-Period. Cache data for a period of time for late subscribers
4. Replay by count and time. A combination of caching by count and period.
5. Replay-All. Cache and replay all values.

It seems to me that the most common usage* of Replay, "Replay(1)" incurs the cost of all the Scheduling and Buffering of the other implementations (Stopwatches, Queues, ImmutableLists of ScheduledObservers and the relevant checks).

My proposal is this: as the _bufferSize_ and _window_ are readonly values of a ReplaySubject, a specialization of the inner workings of the ReplaySubject can be loaded at construction time. For example if the new Replay(1) constructor was called then an internal implementation could be resolved that was specific and optimized for the behavior required by a Replay-one subject :
* Use ImmutableList<IObserver<T>> instead of ImmutableList<SchduedledObserver<T>>,
* no StopWatch,
* no internal Queue of cached values
* no Time and queue depth checks on every OnNext

For Replay(n) where n>1, then an implementation with an intenal queue could be used. Still this implementation would have no need for the ImmutableList<SchduedledObserver<T>>, StopWatch and the time checks on the OnNext call.

The two constructors that take a Window and a bufferSize+Window, could share an internal implemenation as I doubt there would be much perf difference between the two.

Finally the Reply-all behaviour where the parameterless constructor is used, could use the Replay-Many implementation passing Int.Max as a param, but this would still needlessly be calling the Trim method for each OnNext, so again is a candidate for specialization.

*In my opinion Replay(1) would be the most used operation of the ReplaySubject or the associated Replay extension method.
Comments: Hi Lee, Out of curiosity, are you experiencing real problems with the overhead incurred by the _count_ scenarios or did you simply notice that it's unnecessary in the implementation? Note that you can use `Publish(initial)` instead of `Replay(1)`. It uses __BehaviorSubject__ internally, which is essentially just a specialization of `ReplaySubject(1)`, perhaps due to its commonality as you've mentioned. If you don't need the initial value it can be excluded with __Where__, though in some cases you need to use __Select__ also if there is no sensible value to indicate exclusion in a particular domain; e.g., integers can be projected into nullable integers. For example: ```c# IObservable<int> xs = GetObservable(); IObservable<int?> ys = xs.Select(x => new int?(x)); IConnectableObservable<int?> p = ys.Publish(initialValue: null); IObservable<int> q = from x in p where x.HasValue select x.Value; q.Subscribe(...); ... p.Connect(); ``` \- Dave

Created Unassigned: Optimise ReplaySubject for specific cases [35]

LeeCampbell — Wed, 17 Apr 2013 16:38:17 GMT

Commented Unassigned: Rx.Net: Add Silverlight 5 support for portable library [34]

danneesset — Sat, 13 Apr 2013 19:48:15 GMT

Silverlight 5 should support all (or almost all) of the portable library API, please add it to the list of supported platforms for the portable library.

By not supporting Silverlight 5 you prevent everyone else from building portable libraries compatible with SL5 from using Rx. If you wan't async support just utilize the microsoft.bcl.async package since it add async support
Comments: I've looked a bit at the code and I hope t can be solved quite easily by following the following steps. But it would require a new version of all platforms. 1; We need 2 different portable libraries, the current one plus one which is "more portable" (target platforms where IObservable) does not exist. This second portable library would then include the implementation of the IObservable interfaces. BTW: I think it would be a good idea to utilize the Microsoft.Bcl.Async package in order to add task and async support to nearly all platforms. 2; Add TypeForwardedToAttribute's in order to forward the IObservable interfaces to all builds which does not define the NO_RXINTERFACES (like the current portable library). In this way allassemblies compiled against the "more portable" will work with the current portable assembly as well as all current platforms assemblies. You can then choose any of the libraries to compile against with the new portable library allowing us to build portable libraries which target more platforms.

Created Unassigned: Rx.Net: Add Silverlight 5 support for portable library [34]

Daniel_Svensson — Thu, 11 Apr 2013 10:11:42 GMT

Created Feature: RxC++ : Implement Timestamp [33]

kirkshoop — Sat, 30 Mar 2013 18:07:35 GMT

Implement Timestamp operator

Created Feature: RxC++ : Implement Timeout [32]

kirkshoop — Sat, 30 Mar 2013 18:06:56 GMT

Implement Timeout operator