Closed mikebaum closed 8 years ago
As opposed to the previous comment, the solution turned out to be to add the schedule
method to the ThreadChecker
interface rather than the Scheduler
. The Dispatcher
remains unchanged, however, in order to prevent reentrant code from scheduled runnables the dispatcher must be alerted when executing the scheduled runnable. So another commit is required to close this hole.
A potential solution would be to create a back channel through the subscriber chain when applying operators. The back channel will have to signal that a callback is being fired. When the back channel calls reach the source, i.e. a Property or EventSubject, the dispatcher will have to be toggled dispatching on, then off.
Closed as per PR #33.
In order to debounce an event stream it will be necessary to add methods to a dispatcher to be able to schedule a dispatch for a later time. This means that the dispatcher must be thread context aware, in that it must be able to access a scheduler that will execute the dispatch on the correct thread.
Therefore, the scheduler interface will need to have the following method added:
and the dispatcher will require the following method:
As a consequence the creation of a
Property
,PropertyStream
,EventSubject
orEventStream
will be limited to thread contexts that have a known scheduler. For now, this would be the EDT and/or the Fx Platform thread.This impacts testing since many of the tests run on a thread that has no scheduler. Those tests will either have to be updated to make sure they run on either the EDT or the Fx Platform thread or a special test scheduler will need to be created.