I have some automated tests written with Selenium.
Is there any practical difference between using Thread.Sleep vs await Task.Delay?
Both seem to achieve the same thing (cause selenium to wait before continuing execution).
Note that my current understanding is that Thread.Sleep does NOT pause the UI thread, but rather it pauses the Selenium thread. Not sure if this is true however. But if it is true, then i'd imagine there is not practical difference between Thread.Sleep & await Task.Delay.
Related
I have an application that has multiple screens and a process that needs to get UI info from some and update others.
Tried many methods but the result always is always "not a Java FX thread". Without using some kind of thread the UI does not update Because of the multi screen nature of the app (not practical to change) I need to fundamentally change the application architecture which is why I am not posting any code - its all going to change.
What I cant work out is the best way to do this and as any changes are likely to require substantial work I am reluctant to try something that has little chance of success.
I know about Platform.runLater and tried adding that to the updates but that was complex and did not seem to be effective.
I do have the code on GitHub - its a personal leaning project that started in Scala 2 but if you have an interest in learning or pointing out my errors I can provide access.
Hope you have enjoyed a wonderful Christmas.
PS just make the repo public https://github.com/udsl/Processor6502
The problem is not that the Platform.runLater was not working its because the process is being called form a loop in a thread and without a yield the JavaFX thread never gets an opportunity to run. It just appeared to be failing – again I fall foul of an assumption.
The thread calls a method from within a loop which terminates on a condition set by the method.
The process is planned to emulate the execution of 6502 processor instructions in 2 modes run and run-slow, run-slow is run with a short delay after each instruction execution.
The updates are to the main screen the PC, status flags and register contents. The run (debug) screen gets the current instruction display updated and other items will be added. In the future.
The BRK instruction with a zero-byte following is captures and set the execution mode to single-step essentially being a break point though in the future it will be possible via the debug screen to set a breakpoint and for the execution of the breakpoint to restore the original contents. This is to enable the debugging of a future hardware item – time and finances permitting – it’s a hobby after all 😊
It terns out that the JavaFX thread issue only happens when a FX control is written to but not when read from. Placing all reads and writes in a Platform.runLater was too complex which is why I was originally searching for an alternative solution but now only needed it protect the writes is much less a hassle.
In the process loop calling Thread.’yield’() enables the code in the Platform.runLater blocks to be executed on the JavaFX thread so the UI updates without an exception.
The code in the Run method:
val thread = new Thread {
override def run =
while runMode == RunMode.Running || runMode == RunMode.RunningSlow do
executeIns
Thread.`yield`()
if runMode == RunMode.RunningSlow then
Thread.sleep(50) // slow the loop down a bit
}
thread.start
Note that because yield is a Scala reserved word needs to quote it!
I used to consider async as equavelent as multithreading. Multi tasks will be done parallel. However, in javascript I wrote this and it seems that dosomething will never happen.
setTimeout(1000, dosomething)
while(true){}
Why?
Node.js is a single threaded asynchronous language. As mentioned in another answer
Javascript is single threaded (with the exception of web workers, but that is irrelavent to this example so we will ignore it). What this means is that setTimeout actually does is schedules some code to be executed some time in the future, after at least some amount of time, but only when the browser has stopped whatever else it was doing on the rendering thread at the time, which could be rendering html, or executing javascript.
In your example the execution of the while loop never stops, control is never returned to the top level, so the scheduled setTimeout function is never executed.
Multithreading is one of many ways to implement asynchronous programming. Reacting to events and yielding to a scheduler is one other way, and happens to be the way that javascript in the browser is implemented.
In your example, the event that gave you control and allowed you to call setTimeout must be allowed to complete so that the javascript engine can monitor the timeout and call your doSomething callback when it expires.
I am using Coded UI to automate scripts. I am a newbie to C# and I was able to write a hand coded browser script in coded UI and the test passed, but the script execution is dead slow. I assume that some kind of threading has to be disabled. Could somebody please help to resolve the problem -Thanks, Kalaivani
There is a similar question here: Coded UI Test is slow waiting for UI thread
Can you be more specific about what looks like (provide some code) and where it is slow (which methods are taking long time).
Also, have you compared the execution time of Debugging the test vs Running the test?
I am studying the new TPL to make my home made workflow work better.
Right now, I am entered into the maze of Task.Delay and Thread.Sleep. Acutally, Task.Delay(50).Wait() works just like Thread.Sleep(500). So which one should I use in my code?
from the many articles on internet, I have an impression that Task.Delay supports cancellation that Thread.Sleep does not support, so if I want to just block my thread for a duration without cancellation, will the use of Thread.Sleep be better than Task.Delay?
If you require cancellation, Task.Delay is an easy solution to that. I has overhead on top of Thread.Sleep: It constructs a timer and when you wait on this task you construct a wait handle that is signaled by the timer.
That said, you will only notice this overhead in tight loops (and sleep-throttled loops are rarely tight).
Use Thread.Sleep for blocking without cancellation. This is how it has always been done. It is well-known and idiomatic. Use Task.Delay(...).Wait(); for cancellation support.
You can do this in many other ways. For example, construct a SemaphoreSlim or TaskCompletionSource and wait for it using a CancellationToken. That's not as simple as Task.Delay, though.
Maybe Thread.Sleep, which may call Sleep() API directly, will be better than Task.Delay, which create Task object. Task.Deley requires more overhead and a bit more long code.
the easier code is, the better.
I'm quite sure with this, but just to have your opinion:
Is it somehow possible to perform operations in the background with Javascript if web workers are not available?
Is there perhaps a way to "misuse" the asynchronous setTimeout() function or some other mechanisms?
My goal is to read things from the localStorage, do a few transformations and send them via Ajax.
Thanks.
You can't run operation in background, but you can split it in small chunks, and run each next part with setTimeout. As result browser will have time to render changes and will be responsive to normal actions, while your long process will be executed as well
function iteration(){
do_some_small_amount_of_work();
if (!not_finished)
scheduler.setTimeout(iteration, 1);
}
There is not really multithreading in Javascript, but you can run code asynchronously using setTimeout(code, 0). This queues the function for execution.
Without using web workers, what you've suggested (using setTimeout) is the only way to do it, and of course it's not really "background" at all at that point. Note that you'll need to keep the processing quite short each time you fire the "background" code, because it's not really background code at all; while your code is running, the page will be fairly unresponsive (the degree to which it's unresponsive will vary by browser, but certainly any JavaScript code on the page will have to wait for your function call to finish).
No, there is no way to do anything in the background in Javascript. It's strictly single threaded.
You can use setTimeout or setInterval to do the work in the foreground, but just a small part of it each time. That way the interface is still reasonably responsive as it handles events between your bursts of work.