I want to set a timer that emulates a thread that every few milliseconds, calls Dispatcher->ProcessEvents() while inside the main run loop, I'm just rendering and presenting.
In this article, http://msdn.microsoft.com/en-us/library/windows/apps/hh994934.aspx, and near the bottom, it says, "As noted previously, you can also do this with a timer object that you have synchronized to the display device's refresh signal." I'm assuming this can be done since Microsoft has explicitly stated that it could be done.
However, when I attempt this method, if I cache the dispatcher and call dispatcher->ProcessEvents() from inside a periodic ThreadPoolTimer, the events don't get processed.
Any ideas?
Related
I am fetching couchbase mutations through java code similar to run function in https://github.com/couchbase/couchbase-kafka-connector/blob/master/src/main/java/com/couchbase/kafka/CouchbaseReader.java . We subscribe with a io scheduler instead of toBlocking at the end. We get mutations and streamEndMessages but we never get onComplete. Hence the code just waits until killed.
We use core-io-1.2.6, and with top of branch core-io-1.3.0.
This is known limitation at the moment, which will be fixed in next version
Sometimes I'm coding in a wrong way my polymer 1.0 web app and stuff stops to work properly. Like setting data to some custom element and then immediately trying to read some data out of it (that depends on the data just set) (because I don't know better). Sometimes this doesn't work. Most of the time this.async will help me out, but sometimes it will not. However, setTimeout has never ever failed me in these kind of situations. Most of the time calling setTimeout without providing wait time will work just as well.
For a long time I thought that this.async(function(){...}) is the same as setTimeout(function(){...}). Because sometimes code inside this.async will fail to see changes in custom element's data while code inside setTimeout will not.
Are these two methods are implemented in different way?
this.async adds your function to the start of the event queue, while setTimeout adds it to the end. If you use setTimeout other functions may have been executed before your function is called, causing the changes that you can see in your data.
From the documentation of this.async:
If no wait time is specified, runs tasks with microtask timing (after the current method finishes, but before the next event from the event queue is processed)
setTimeout on the other hand will add your function to the end of the queue as is described in the section "Adding Messages" of this article.
Calling setTimeout will add a message to the queue after the time passed as second argument. If there is no other message in the queue, the message is processed right away; however, if there are messages, the setTimeout message will have to wait for other messages to be processed. For that reason the second argument indicates a minimum time and not a guaranteed time
What's the purpose of async method in polymer? When should I use it?
Right now I'm using it like hm-this-bug-is-kinda-weird-maybe-async-will-fix-it-yep-id-did-yey. It does not give me any confidence in my code as I'm sprinkling async just when some timing bug shows up.
The answer is slightly different here depending on whether you're using Polymer 0.5 or 1.0. In 1.0, more operations are synchronous, so you may not see quite as much need for async (also, the async method works slightly differently in 1.0).
Let's start with 0.5. Most of the cases have to do with the effects of changing properties. Properties used in data bindings or observers are observed for changes. When you change one of these
properties, any side-effects of that change take place asynchronously, with microtask timing. That means that the work happens after the current event handler returns, but before the next event is processed.
In other words, if I have a data binding like this:
<div id="output">{{someProperty}}</div>
Suppose I have the following code:
this.someProperty = "New Value";
console.log(this.$.output.textContent); // logs "Old Value"
This is where the asynchrony bites you. If you want the bound data to be updated, you need to give the data binding system a chance to work. If you move that console.log statement into an async, so it's executed at a later time, you get the response you expect:
this.async(function() {
console.log(this.$.output.textContent); // logs "New Value"
});
Most of the time, you don't need to poke at data bound DOM elements. But in the event that you do, or that you're waiting on the side effect of an observer, you probably want an async.
In Polymer 1.0, data binding and single-property observers are synchronous. Multi-property observers and some DOM operations are async.
(While the APIs are different from JavaScript, this Dart article about the event loop is the best one I've found to describe the event loop and microtask queue: https://www.dartlang.org/articles/event-loop/)
I been using the WebService and Operation classes of Flex Framework for a while, and after some ups and downs (more downs than ups, haha) I'm in process of refactoring all its uses with some utility classes/wrappers.
After browsing a little of the code of mx.rpc.soap.Operation I noticed that when you use the method "send" and the web service is not ready then the call is queued to an internal array (pendingInvocations:Array in line 1142). But the funny thing is that the invocations in the queue are never called again.
This is a bug or there is something I'm doing wrong?
I'm considering extending mx.rpc.soap.Operation, overriding "send" and testing if there are invocation queued, calling invokeAllPending (a mx_internal method that pops all the queued invocations) my self.
But the other problem is that that method is mx_internal, so I don't know if Adobe is gonna change it any time soon.
Any advice?
Thanks in advance
It's not a bug. Take a look at the definition for AbstractWebService; it defines a method called unEnqueueCalls (which is right up near the top of the list of awkward method names that I've seen :)). This method loops through all the operations in the webservice and invokes the pending calls for each operation by calling that invokeAllPending method you found.
unEnqueueCalls is itself called from the WebService class, in the wsdlFault and wsdlHandler methods, one of which runs when your WSDL is finished loading.
So, everything is all accounted for; you don't need to override anything.
Let suppose I create a class, and in this class I declare a method that will run a loop.
My question is what will be behavior of loop, if I dispose the object of class and condition of loop is yet true - will loop execute or terminate.
Usually the object (variable) is managed by a single thread. So you may not be able dispose of easily because the thread is still running in the loop. If you mult-thread and you call in a method that modifies this variable (your object) on the a different thread you may crash your program. If your loop in a UI thread which has a message pump (sta thread) and you call a method directly from another thread then you app will crash as this is not allowed.
All in all what do you want to do ? Mark Byers's condition "The code keeps running" is the most possiable outcome of this I think. But you have a bug either way - don't attempt to drive a car and then just jump out of it without stopping.