I use a specific tool to inspect my app. Once the app hits a breakpoint I can invoke my tool from the Immediate Window by calling a certain function. The tool itself is a multi-threaded Windows App and therefore spawns some tasks.
The problem that I am facing is that sometimes some tasks scheduled from the tool are never run which causes my tool to hang indefinitely. I spawn tasks with ThreadPool.QueueUserWorkItem or with Task.Run and they both cause the tool to hang and never execute these tasks. If I use Thread class instead the tool works perfectly.
Also, the tool works (with Tasks) if started normally i.e. not from the Immediate Window. Therefore the problem occurs only if I use Tasks and Immediate window.
Thus, my question is what might be the reason that some tasks are never executed? I understand that Immediate Window blocks all other threads and executes the command on the thread which hit the breakpoint, but the threads/tasks spawned from the Immediate Window thread should be still executed, right?
Both my app and the tool are in C#.
I am using Visual Studio Professional 2015 Update 1.
Immediate window, in contrast to step-by-step debugging, does only execute asingle thread at a time - the main or the current thread. It Cannot invoke new threads or tasks. Therefore your tool will stuck.
Related
I've created a GUI application in Powershell. It's designed to use a RunspacePool to multi-thread its requests in the background, and this works perfectly fine from PowerShell natively.
However, when I convert the file to an EXE using PS2EXE, it needs to use Single Thread Apartment (STA) since it's a GUI. It gives me errors if I try and run it as MTA. And then when the EXE runs as STA, it performs its activities at a fraction of the speed it should, as if it is still just using one thread.
Is a STA not able to initialise other threads for background tasks? Or will I need to configure the application as a MTA but explicitly hang the user interface on its own thread?
Maybe it's a simple question, but I don't get it. When should I use concureency in my javafx project? Is it right that I should use for every task, which do some action in the background, the Concurrency API? So every action in my controller class, which has nothing to do with the UI should be executed in a single task?
I really don't get it how to use this right....
Whenever you have a task that may take sometime to get executed or there is a possibility of delayed response, you do not want your JavaFX Application thread to wait for it, because, as long as the JavaFX Application thread waits for the response, the UI becomes unresponsive.
A few examples where you may want to use a background thread is :
An I/O operation
A web service call
From the JavaFX documentation :
Implementing long-running tasks on the JavaFX Application thread inevitably makes an application UI unresponsive.
On the other hand, if you have minor calculations or some task which can be completed in a jiffy (I am not sure if this is the correct word, but I hope you can relate to what I want to say) and will not put the JavaFX Application thread on wait, you can execute them on the same thread.
Hi am developing a windows phone 8 app using C# and xaml.
My previous team has developed some code, they have used many methods in timer control.
when it is updating all the methods are calling and its blocking the UI.
Is there any another way to use the timers asynchronously so that the UI can not be blocked.
Thanks in advance
you should use the "xaml binding" to updating the UI
There are several Timer classes in Windows Phone.
System.Windows.Threading.DispatcherTimer: runs on UI thread and makes UI unresponsive when executed.
System.Threading.Timer: executes on a ThreadPool thread, therefore can not update UI directly. For an example how to make a cross-thread call to update UI, see the example in the link.
There is also a ThreadPoolTimer, seems it works like a System.Threading.Timer - runs on ThreadPool thread, just has different methods. But I have not used it.
So to answer your question, if a timer event blocks UI, then it is likely a DispatcherTimer, replace it with System.Threading.Timer, reference the code sample in the previous link.
Did you try using the DispatcherTimer?
How to Increment timer asynchronously ?
Or else you could go with the CountdownTimer.
How do you run a synchronous timer in C#?
as #kennyzx said there are many ways to do it, but the choice is yours.
a sample on CountdownTimer from the Toolkit
I am trying to track down the reason why my WPF application is not ending cleanly while debugging. By 'cleanly' I mean that all the windows are closed, I can see various messages in the Output window showing that the app has ended but the process is still active and the 'Stop' button in the debugger is still active.
I call the Shutdown() method but something is stopping the application from ending. I am pretty sure it has something to do with the ethernet connection to an IO device but cannot see what I am doing wrong. (When I comment out the call to connect the device the app can exit cleanly)
I was wondering if VSE 2010 can list all active threads as this might give a clue as to what is still 'alive' after the main program ends. Or is there an external tool that might help here?
You should be able to use the Visual Studio Threads window to see which threads are still active. I'm not entirely sure this window is available in the Express edition (the documentation doesn't mention such a limitation), but should you not have it, then you can also use WinDbg to list all threads. WinDbg is part of the debugging tools for Windows. You might need to install the latest version of the Windows SDK to get it.
Use the debugger first. Debug + Break All, Debug + Windows + Threads to see what threads are still running. You can double-click one and use Debug + Windows + Call Stack to see what it is doing. The typical case is a thread you started but forgot to tell to terminate. The Thread.IsBackground property is a way to let the CLR abort a thread automatically for you.
Technically it is possible to have a problem with a device that prevents a process from shutting down. The Threads window would then typically show only one thread with an otherwise impenetrable stack trace. If you use Task Manager, Processes tab, View + Select Columns, tick Handles, then you may see only one handle still in use. The diagnostic then is that you have a lousy device driver on your machine that doesn't properly support I/O cancellation. Which could leave a kernel thread running that doesn't quit, preventing the process from terminating. Very unusual, look for the reasons given in the first paragraph first.
I'm debugging a multi-thread delphi app.
We are having a trouble that, after connect to the server, the client app is getting 100% of the CPU.
Is there a way for me to debug and know shich thread is dois that?
Process Explorer will give you usage details down to the thread level for any process.
Run your app
Run Process Explorer (after downloading it ;-)
Double click on your executable in the process list
Select the Threads tab and there you will see:
The Thread ID
CPU Usage
Cycles Delta
And the start address
The TID ought to be enough to nail down your CPU hogging thread.
As Paul Sasik suggests, Process Explorer is probably what you want to do. If your debugging strategy involves monitoring code that is in your application itself, use GetThreadTimes.