From what I understand, the entire client side of a GWT application is converted to Javascript when you build, therefore I suppose this question is related to both Javascript and the possibilities that GWT offers.
I have a couple of dozen processes that will need to be initiated in my GWT application, each process will then continuously make calls to a server. Does GWT support threading? Does the GWT client side support threading?
EDIT:
This link states:
No JavaScript knowledge required If you’re just a user of the framework,
which I am for the matter of discussion, you do not need to know JavaScript
in order to write dynamic content, be it client-side such as rolling frames,
docking panels or scheduled “multi-threading” tasks, or server-side calls
using XMLHttpRequests (aka AJAX).
or scheduled “multi-threading” tasks, what does this mean?
JavaScript doesn't support multithreading. However, GWT has a class to 'simulate' threading, which is not real multithreading, but in most cases does what you need: com.google.gwt.core.client.Scheduler.ScheduledCommand. The technique is based on the timer class, which executes a method after the given time elapses.
For example, when placing the following code in you own code, the scheduleDeferred method will return directly and your code continues after the command, while the execute() method is executed using the timer:
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
public void execute() {
.. code here is executed using the timer technique.
}
});
You can create a repeating command RepeatingCommand, which can be used to run the command more than once. Start it with Scheduler.get().scheduleIncremental() that will execute the command until the execute method returns false. You can use this to split tasks into sub tasks to get better 'threading' behavior. The Scheduler supports some additional methods to start a scheduled command differently. See the JavaDoc for more details.
Edited and updated with new GWT class instead of the deprecated DeferredCommand.
There is work on Web Workers as part of HTML5 that is implemented in a number of browsers, but not on all (most notably internet explorer). You could use these features where available, but what you should do is look at the javascript programming model.
Javascript generally works asynchronously. Requests are fired off and at some point their answers are received as an event. You can have a large number of pending requests at the same time. This will require a bit of a redesign of your system though.
New way is to use a Scheduler
JavaScript doesn't support multithreading, so whatever GWT does, multithreading has to be done solely on the server side, because GWT can only use features that are already available on the client side.
Related
A VkFence can be waited upon or queried about its state. Is it possible to have a callback invoked by the Vulkan implementation when the fence is ready instead?
This would allow it to be used with objects such as a std::condition_variable. When the fence would be ready, the condition_variable would get notified.
Such an approach would also allow integration with libraries like Boost.Fiber, which would completely remove the need for the thread to sleep, but rather it could do useful work while waiting upon the fence.
If this is not possible in base Vulkan, is there an extension that allows it?
Vulkan doesn't work that way. Vulkan devices and queues execute independently of the CPU. Indeed, with one or two exceptions, Vulkan implementations only ever use CPU resources within the scope of a particular function call and only on the thread on which this call was made. Even debug callbacks are made within the scope of the function that caused the error.
There is no mechanism for Vulkan implementations to use CPU resources without the explicit consent of the user of the API (again, minus one or two exceptions). So no callbacks that act outside of an API call.
Vulkan does have a way to extract a native synchronization object from a VkFence, but it is surprisingly not useful in Windows. While you can get a HANDLE, it cannot be used by the Win32 API for waiting on it. This is mainly for interop with other APIs (like converting it to a D3D12 sync object), not for waiting on it yourself. But the file descriptor extraction operation can get a fully functional sync object... if the implementation lets you.
I have an user interface and provide a button to the user, which executes the function longComputation(x: A): A and updates then the user interface (particularly the model) with the new result. This function may take longer to compute the result and should therefore compute in parallel.
Diode provides me with Effect, PotAction, and AsyncAction. I read the documentation about Effects and PotActions/AsyncActions, but I cannot even get a simple example to work.
Can someone point me to or provide an simple working example?
I created a ScalaFiddle based on the SimpleCounter example. There is a LongComputation button, which should run in parallel; but is not.
In JavaScript you cannot run things in parallel without using Web Workers because the JS engine is single-threaded. Web Workers are more like separate processes than threads, as they don't share memory and you need to send messages to communicate between workers and the main thread.
Have less than 50 reputation to comment, so I have to create a new answer instead of commenting #ochrons answer:
As mentioned Web Workers communicate via message passing and share no state. This concept is somehow similar to Akka - even Akka.js exists which enables you to use actor systems in ScalaJS and therefore the browser.
Currently, I'm using the powerful SetWinEventHook() function to catch some user-interface's actions like minimizing and maximizing from other window runned by programs on the computer.
So I inspired myself by using the code provided by BrendanMcK on this post and it does work (I mean: the callback function is called when an event occurs) until the line
MessageBox.Show("Something")
is present. But I don't want to use any form or window for this program..
After some research, I figured out this kind of hook needs a message loop to allow the redirection of messages from other window handles. Apparently, calling the thread using Application.Run() should do the trick, but I would prefer something cleaner, in the C# object itself.
So my question is: is it possible to create a message loop inside an object's method?
http://bytes.com/topic/c-sharp/answers/557342-thread-message-loop-c
No, the function doesn't require a window handle so no "form" is needed. But the MSDN docs for the function is quite explicit:
The client thread that calls SetWinEventHook must have a message loop in order to receive events.
A message loop is universal in any program that want to receive notifications that are generated externally by other processes or threads. It is the common solution to the producer-consumer problem. Clearly any GUI app has a need for such a solution, Windows messages are generated by the operating system. It isn't different for SetWinEventHook(), the accessibility events originate in other programs. There is no clean mechanism to "interrupt" a thread and make it run other code, the re-entrancy problems that causes are extremely difficult to deal with. The thread has to co-operate, it must be idle and ready to receive a notification to safely process it. A message loop solves that problem.
Pumping a message loop (calling Application.Run) in a method is certainly possible. But do keep in mind that the method won't return until you explicitly stop the loop with Application.ExitThread. There is therefore usually only one good place for that call, the Main() method of your program.
Starting your project with a Winforms or WPF project template is a very good way to get this right. You have no need to actually create a window, call Application.Run() without an argument, after pinvoking SetWinEventHook.
When writing Swing or AWT applications, I'm aware that GUI changes should always be done in the EDT. How does this translate to writing GWT applications?
I'm looking at a scenario when I call the following.
myRequestBuilder.sendRequest(myRequestDate, myRequestCallback)
myRequestCallback modifies the GUI. Having such a construct in Swing, I would make sure that the myRequestCallback invokes the EDT for the GUI changes. Does GWT require me to do something similar as well?
On the web (in browsers), it's dead easy: everything always executes in the event dispatch thread.
See also http://www.html5rocks.com/en/tutorials/workers/basics/
Workers JSNI at GWT svn
It looks like WebWorkers have not been fully implemented yet. I know that elemental is in early stage of development but might be someone already have tried to make it works?
The problem with web workers is that they don't really fit the standard GWT/Java model - in my opinion they barely fit the standard JS model.
Web workers work by passing data back and forth between what are essentially different JavaScript VMs. That data must be in the form of a string, and each worker has to load its JS separately. This means that no variables declared in one worker (or the main page) is accessible from another, unless it is passed as part of the string data, pushed back and forth between workers.
So how does this work when you consider GWT/Java? From the Java perspective, this is not equivalent to multiple threads, but multiple JVMs! The different processes can only communicate by passing Strings (or more importantly, not Java objects) back and forth, and cannot share any other state. Even static variables might be different between the two virtual machines.
From the link you posted, check out the source of JsWorker - you can create an instance of this via JsWindow.newWorker with the url of the JS script to start with, and JsWorker supports methods to listen for responses, and to send it messages to give it work to do.
That script could be a GWT compiled object - but it would be a separate module and entrypoint than the original app, so that it only has the code it can reasonably run, and doesn't try to start drawing on the page when it loads. It would probably need to use a linker that would only load the JS, and wouldn't assume an iframe on the 'page'.
The GWT-NS project has some web worker samples already, built using their own linker to construct js files to load to load in the worker, and some other convenience pieces as well.