I have an app that has multiple threads. Some of the threads are using libraries that are built on top of the pthread API.
Reading through the docs it seems that at one time you had to call gdk_threads_enter and gdk_threads_leave.
But looking at the docs, the whole lot seems to be deprecated. Now they are saying you need to do everything from the main thread. But after the main_thread enters gtk_main() how am I supposed to signal that thread to e.g. refresh some widgets like a menu I'm building dynamically from another thread which pulls the menu items from a REST web service and is long running. I assume I shouldn't just do that from the other thread according to the documentation. Although it's guarded with a lock and still appears to work. I do get occasional crashes and I'm not really sure if it's because of this this.
Gtk:: widgets are not thread safe. So, never update Gtk::Widget inside a thread, update the widget inside a timer function which gets started on a regular period.
Related
I have an application which uses WPF for its GUI but, on command kicks off a very heavy processing load.
I noticed that my GUI was rather sluggish when the engine (heavy processing) was running and when using the 'Application Timeline' tool in VS2015, I noticed that some of my engine code was being run on the UI thread.
The engine is started with the following line which, if i understand the LongRunningflag, creates a new thread and runs the given function on that thread.
rootTask = Task.Factory.StartNew(DoWork, TaskCreationOptions.LongRunning);
The DoWork method referenced above repeatedly uses Parallel.For to queue up hundreds of tasks.
Is it possible that the dispatcher thread is 'helping-out' by running tasks from the TaskScheduler queue? If so, is it possible to prevent this to keep the GUI responsive (allbeit to the detriment of the background tasks)?
Is it possible that the dispatcher thread is 'helping-out' by running tasks from the TaskScheduler queue?
No, as far as I know, that's not possible. If some code that comes from the Task really executes on the dispatcher thread, then that means the task had to explicity schedule it there.
The way I am waiting on a thread to start is by creating an event, and when I create a thread, I pass it this event, and when the thread starts executing, it signals this event (which I am already waiting on). I have no problem with this approach, but I am wondering if Windows provides a special function for this.
Your current solution is a perfectly good solution to the problem. You've no reason or need to look for a better solution. Certainly the threading API doesn't offer you any built-in mechanism so you do have to implement something. And what you are doing is a fine way to solve the problem.
Is it possible to make a synchronous network call on UI thread in WPF (Windows Phone 8).
(I know it's cons, but still i need this functionality to make it work with some ported code)
Tried using autoresetevent method. Due to deadlock, it is blocking ui thread and app hangs forever.
Even tried with webclient. still the UI thread is getting blocked and app hangs forever.
Any help...
This is a very bad idea - I've found that doing this by accident will actually lead to a complete deadlock of your UI. You need to use an asynchronous method.
Callbacks from asynchronous network operations are queued on the UI thread. If you block the thread to wait for it, the callback will never arrive because it is waiting for access to the same thread.
You do have another option though... If you have ported the code, then you will have to change it to support async operations.
I need some help understanding the difference between STA and MTA with respect to the winform and console application. I am using a third party COM interface to execute functions in parallel, using parallel.invoke. When i do this in console application everything works fine and code actually runs in parallel. But when i do the same thing in Winform it's sequential, and if i remove the STAtrhread tag above the entry point of winform , it start to work fine in parallel. Can anyone explain this behavior?,Any suggestions would be nice!
COM has a feature that's entirely missing in .NET. A COM class can specify whether it is thread-safe or not. It does so with a key in the registry named ThreadingModel. Just like most .NET classes, the vast majority of COM classes are not thread-safe so they specify "Apartment". Which is a somewhat obscure term that implies "only call me from the thread on which I was created". Which automatically provides thread-safety.
To make that work, a thread that creates COM objects has to indicate what kind of support it is willing to provide for COM classes that are not thread safe. An STA thread is a safe home. Requirement is that the thread pumps a message loop, like any UI thread does. The message loop is the mechanism by which COM marshals a call from a worker thread to the thread that created the object. A thread that joins the MTA specifically says it does not provide support.
COM has to do something about MTA threads, they are not suitable for COM objects that are not thread safe. It creates a new thread, an STA thread to give the COM object a safe home. That's quite inefficient, every method call has to be marshaled. And risky, a COM class may still be thread-unsafe if its objects share state internally.
So what's happening in your Winforms case is that you created all the objects on the main thread, which is an STA. And make calls from parallel worker threads, those calls all get marshaled and serialized back to the STA thread. Inevitably, they execute one-by-one and you get no concurrency.
In your Console case, you created them on an MTA thread. So COM is forced to create threads for each object. The method calls on your worker threads are still marshaled, but now to multiple threads. So now you do get concurrency, at the cost of significant overhead, a bunch of extra threads. And the risk of failure when the server shares state internally.
Make the Winforms case the same as the Console case by creating the COM objects on a worker thread. Do test it very thoroughly.
STA and MTA are both "threading models" for COM/ActiveX, dating back to the mid 1990's.
Here's a good link:
http://msdn.microsoft.com/en-us/library/ms809971.aspx
STA:
A process has one single-threaded apartment (STA) for each thread that
called CoInitialize. Each of these apartments, in turn, may have zero
or more COM objects associated with them. As the name implies,
however, only one specific thread (the thread that created the
apartment by calling CoInitialize) may directly access the objects
within the apartment
MTA:
Although multi-threaded apartments, sometimes called free-threaded
apartments, are a much simpler model, they are more difficult to
develop for because the developer must implement the thread
synchronization for the objects, a decidedly nontrivial task. On the
positive side, removing an STA's synchronization mechanism gives the
developer much finer control over the use of thread synchronization.
They can apply it where it is actually needed rather than taking the
very conservative approach of STAs, which synchronize access to the
entire apartment.
One issue is choosing the best threading model for your component (the default is STA, IIRC). Another issue is what the runtime will do if you need to marshal data between your component and a component that uses a different threading model. The link above discusses both.
I have a very complex WPF application where the pages that I display and processed are in dlls. This works fine so far.
I set up a timer in the main page of the app that looks for communication coming in from an external source. When I get a communication (and I am being vague to not not add confusion) I parse it and if the message is "xyx" I need to start the XYL dll's UI. I get the calling thread must be sta bacause many ui components require this.
I see the write ups on the web about having to call the Invoke() and that I can't use a worker thread but rather a background thread.
Is my problem the System.Timers.Timer that I am using? Is that causing a worker thread? I am not sure where in my calls I need to start a thread to run this (or how to handle it).
Any suggestions?
System.Timers.Timer runs on a worker thread and cannot access UI elements. See here and here for more information on that.
It's ok to use that kind of timer, you just need to get back to the UI (dispatcher) thread before you touch the UI pieces. You can do this by calling Dispatcher.Invoke or Dispatcher.BeginInvoke and passing in the delegate you want to run. That'll get the new UI pieces onto your original UI thread. If you want them to run on their own UI thread (perhaps in a different window) then you need to set that up yourself.
Timers normally run on a threadpool thread which are MTA.
Use a DispatcherTimer instead or use Dispatcher.Invoke. The dll's UI will then run on the same thread as main page's UI (which is STA)
If you want the dll's UI to run on a different thread you need to create the thread yourself and set it to STA.