I know that Actionscript is not multi-threaded. But, I want to address this somehow. I need to make multiple requests to the server while the UI is being rendered (UI renders multiple graphs).
I found this article and I am exploring how to make best of use of this for my situation.
Is there any alternative friends?
1) in flash ALL remote calls (like RemoteObject, URLLoader, HTTPService etc) are asynchronous. So you do not need any multi-threading for server request - UI will not be frozen!
2) In FlashPlayer 11.4 and Air 3.4 multi-treading became possible, but not really used yet in known applications...
See these:
http://helpx.adobe.com/flash-player/release-note/fp_114_air_34_release_notes.html
http://www.bytearray.org/?p=4423
3) also, it is possible to avoid UI freezing for long process operations in flash using delays and calling over timeouts, like in example of asynchronous JPEG encoder:
Fast or asynchronous AS3 JPEG encoding
http://www.switchonthecode.com/tutorials/flex-tutorial-an-asynchronous-jpeg-encoder
http://blog.inspirit.ru/?p=201
Related
Does Go have an equivalent of node.js' "emitter"?
I'm teaching myself Go by porting over a node.js library I wrote. In the node version, the library emits an event once something happens (e.g. it listens on UDP port 1234 and when "ABC" is received, "abcreceived" is emitted so the calling code can respond as necessary (e.g. sending back "DEF")
I've seen channels in Go (and am currently reading up on them), but as I'm still new to this language, I don't know if (or how, for that matter) that can be used to communicate with whatever code is using my library.
I've also seen https://github.com/chuckpreslar/emission, but am not sure if this is acceptable, or if there's a better ("Best practice") way of doing things.
Go and Node.js are very different. Node.js supports concurrency only via callbacks. There might be various ways of dressing them up, but they're fundamentally callbacks.
In Node.js, there is no parallelism; Node.js has a single-threaded runtime. When Node.js async is used to achieve what is called 'parallel' execution, it isn't parallel in the sense used in Go, but concurrent.
Concurrency is not parallelism in the Go world.
Go has explicit concurrency based on Communicating Sequential Processes (CSP), a mathematical basis conceived by Tony Hoare at Oxford. The runtime interleaves cooperating processes called goroutines by time-slicing them onto the available CPU cores. Within each goroutine, the code is single threaded, so is easy to write. In the simple case, no data is shared between goroutines; instead messages pass between them along channels. In this way, there is no need for callbacks.
When goroutines get blocked waiting for I/O, that's OK because they don't use any CPU time until they're unblocked. Their memory footprint is slight and you can have very large numbers of them. So callbacks are not needed for I/O operations either.
Because the execution models of Go and Node.js are about as different as they could be, attempting to port code from one to the other is very likely to lead to very clumsy solutions. It's better to start from the original requirements and implement from scratch.
It would be possible to distort the Go concurrency model using function arguments to behave like callbacks. This would be a bad idea because it would not be idiomatic and would lose the benefits that CSP gives.
So by reading others' Go code and some links in the comments to my question, I think channels are the way to go.
In my library code (semi pseudo-code):
// Make a new channel called "Events"
var Events = make(chan
func doSomething() {
// ...
Events <-"abcreceived" // Add "abcreceived" to the Events channel
}
And in the code that will use my library:
evt := <-mylib.Events
switch evt {
case "abcreceived":
sendBackDEF()
break
// ...
}
I still prefer node.js' EventEmitter (because you can transfer data back easily) but for simple things, this should suffice.
Hi I’m currently working on a project for a videocoacher program for recording and replaying video, as well as showing delayed real-time video, and tracking placement via color.
The software is running on linux , on a 4 core odroid, and initially I started to make it multi threaded with threads implemented as a part of each new class. Each of these threads taking care of their own gui elements.
I’ve later found out that I need to show all gui elements/video in the main/gui thread. Earlier I’ve used opencv and boost. But it seems like using the Qt might be a better idea since some of the code already depends on the QT library. I am currently a novice at programming, and not very familiar with either opencv, qt, or threading.
My question is:
Is this relatively sound as a structure for the program, or is there something inherently wrong with how I am planning to do it now?
Main/GUI Thread
will show all visual & video content
will start a thread for ButtonControl object
ButtonControl
will handle all button input, controlling what happens in the program
depending on what buttons are pressed will start and end threads
like:
StoreToFile object ( starts storing video to a file, while sending a
video stream to GUI thread to show what it is storing in real-time)
ReadFromFile object ( reads the file currently stored and sends data
to display it in GUI thread
DelayedVideoStream object (stores video to buffer, and shows a
continuous delayed view of what happened 5seconds in the past)
ColorTracking object (tracks where a color placement is in the image
)
Kind regards, and thank you for taking the time to look at my question.
TLDR - is a structure where threads are implemented as classes and the image data is sent back to the gui/main thread a decent way to do a multithreaded program ?
Performance-wise, the best approach is not to deal with threads directly at all, but use QtConcurrent::run. It is safe to paint QImages that are simply passed via signals to a GUI object to display. I wrote a complete example demonstrating that approach. It leads to some very concise and easy-to-understand code thanks to related code being adjacent.
If you do want to use explicit threads, it will be much easier not to derive from QThread, but to simply move various worker objects into their threads, and have them communicate via signals and slots. I have a complete example for that approach as well.
Why does this crash FireFox? Copy and paste this code into the browser console (Ctrl+Shift+J):
function TestRunner(){}
TestRunner.prototype={
classDescription:"TestRunner",
classID:Components.ID("{09AA3487-7531-438D-B0B2-80BC24B584C0}"),
contractID:"#yoy.be/TestRunner;1",
QueryInterface:XPCOMUtils.generateQI([Components.interfaces.nsIRunnable]),
run:function(){
console.log("ping");
}
};
Components.classes["#mozilla.org/thread-manager;1"].getService().newThread(0).dispatch(new TestRunner(),0);
Starting with Firefox 4(-ish) the whole Javascript engine became far less thread safe, to the extend where e.g. simple things such as just "reading" a string concurrently may cause memory corruption (because these reads might actually materialize strings views for string ropes).
Therefore it was decided that dispatching javascript-implemented nsIRunnable isn't supported anymore as there is no safe way to use it, and people should switch over to ChromeWorkers where possible.
Edit You said in the comments that you wanted to implement nsIChannel/nsIProtocolHandler. AFAIK you can implement nsIProtocolHandler and nsIChannel without any threads and binaries. If you still have to have threads and/or binaries, then your Javascript XPCOM (stub) components would "simply" communicate with a ChromeWorker via message passing (pass around ArrayBuffers/typed arrays; those are zero-copy). The ChromeWorker would then do any heavy lifting, incl. any js-ctypes calls to interface with binaries.
You can run non-XPCOM JavaScript on other threads using (chrome) workers, and you can dispatch C++ implementations of nsIRunnable to other threads, but you can only use XPConnect on the main thread. This is because XPConnect objects could be cycle-collected and the cycle collector isn't threadsafe.
I am aware that Action Script does not provide multithreading so when writing flex application we are limited to work on one thread. which is ok for rendering my UI.
However some questions arise when preferring flex over silverlight:
As a UI layer single thread is good enough but is it fair to assume that for Aync httpservice like operations in flex , internally it would use some worker threads to manage the async operation and then come back to the main thread ? it looks like it does since my UI does not freeze.
Can the flex/flash player deal with multiple httpservice calls in parallel ? ( e.g more than one section of the UI loading data at the same time.)
How about the animation stuff ( e.g the parallel animation ) - does flash player internally leverages some threading for accelerating graphics or is it all done on the UI thread ?
but is it fair to assume that for Aync httpservice like operations in flex , internally it would use some worker threads to manage the async operation and then come back to the main thread
No.
Processing of the response data occurs in the same thread as updating the UI. For example, if you return 5,000 AMF objects in a single call, the Flash Player will deserialize these on the thread, which will cause the UI to freeze.
Internally, the browser may be using threads to manage the loading of the response from the end URL. However, once the response has been returned, and handed off from the browser to the Flash player plugin, the deserialization and processing of that data occurs on the main thread.
Can the flex/flash player deal with multiple httpservice calls in parallel ? ( e.g more than one section of the UI loading data at the same time.)
Yes.
The limitation here is enforced from the browser, in the maximum number of concurrent HTTP requests that the browser. This varies from browser-to-browser, but generally speaking, it's fine (and encouraged) to send multiple requests to backend services.
It's worth familiarizing yourself with AsyncToken, which is Flex's main class used when handling concurrent calls, ensuring that the request and response are matched together.
Be aware that most classes in Flex which are used for communciating with remote services (eg., HttpService and RemoteObject) expose a concurrency property, which defines how the object should react to multiple concurrent requests. (Allowing the developer to explicilty allow or prohibit it).
How about the animation stuff ( e.g the parallel animation ) - does flash player internally leverages some threading for accelerating graphics or is it all done on the UI thread ?
This is not my area of speciality, and someone may correct me. However, I believe that Flex creates animations by generating a series of KeyFrames which change the properties of values on a UIComponent over time, and then executing them. (The execution occurs in the same thread as everything else).
Therefore, Parallal animations are generated by aggregating the targets for the keyframes, and executing them together.
eg: Keyframe n at ms300 = { UIComponent1.x = 300; UIComponent2.y = 300 }
In WinForms, pretty much all your UI is thread-specific. You have to use [STAThread] so that the common dialogs will work, and you can't (safely) access a UI element from any thread other than the one that created it. From what I've heard, that's because that's just how Windows works -- window handles are thread-specific.
In WPF, these same restrictions were kept, because ultimately it's still building on top of the same Windows API, still window handles (though mostly just for top-level windows), etc. In fact, WPF even made things more restrictive, because you can't even access things like bitmaps across threads.
Now along comes WinRT, a whole new way of accessing Windows -- a fresh, clean slate. Are we still stuck with the same old threading restrictions (specifically: only being able to manipulate a UI control from the thread that created it), or have they opened this up?
I would expect it to be the same model - but much easier to use, at least from C# and VB, with the new async handling which lets you write a synchronous-looking method which just uses "await" when it needs to wait for a long-running task to complete before proceeding.
Given the emphasis on making asynchronous code easier to write, it would be surprising for MS to forsake the efficiency of requiring single-threaded access to the UI at the same time.
The threading model is identical. There is still a notion of single threaded and multi-threaded apartments (STA/MTA), it must be initialized by a call to RoInitialize. Which behaves very much like CoInitialize in name, argument and error returns. The user interface thread is single threaded, confirmed at 36:00 in this video.
The HTML/CSS UI model is inherently single threaded (until the advent of web workers recently, JS didn't support threads). Xaml is also single threaded (because it's really hard for developers to write code to a multithreaded GUI).
The underlying threading model does have some key differences. When your application starts, an ASTA (Application STA) is created to run your UI code as I showed in the talk. This ASTA does not allow reentrancy - you will not receive unrelated calls while making an outgoing call. This is a significant difference from STAs.
You are allowed to create async workitems - see the Windows.System.Threadpool namespace. These workitem threads are automatically initialized to MTA. As Larry mentioned, webworkers are the JS equivalent concept.
Your UI components are thread affined. See the Windows.UI.Core.CoreDispatcher class for information on how to execute code on the UI thread. You can check out the threading sample for some example code to update the UI from an async operation.
Things are different in pretty important ways.
While it's true the underlying threading model is the same, your question is generally related to how logical concurrency works with UI, and with respect to this what developers see in Windows 8 will be new.
As you mention most dialogs previously blocked. For Metro apps many UI components do not block all. Remember the talk of WinRT being asynchronous? It applies to UI components also.
For example this .NET 4 code will not necessarily kill your harddrive because the UI call blocks on Show (C# example):
bool formatHardDrive = true;
if (MessageBox.Show("Format your harddrive?") == NO)
formatHardDrive = false;
if (formatHardDrive == true)
Format();
With Windows 8 Metro many UI components like Windows.UI.Popups.MessageDialog, are by default Asynchronous so the Show call would immediately (logically) fall through to the next line of code before the user input is retrieved.
Of course there is an elegant solution to this based on the await/promise design patterns (Javascript example):
var md = Windows.UI.Popups.MessageDialog("Hello World!");
md.showAsync().then(function (command) {
console.log("pressed: " + command.label); });
The point is that while the threading model doesn't change, when most people mention UI and threading they are thinking about logical concurrency and how it affects the programming model.
Overall I think the asynchronous paradigm shift is a positive thing. It requires a bit of a shift in perspective, but it's consistent with the way other platforms are evolving on both the client and server sides.