I'm using libnotify to show desktop notifications in my application; notify_notification_new() returns a NotifyNotification*, which should be passed as the first param to further function calls of the notification library.
There is no notify_notification_free() which frees the pointer it returns. I looked up the source of notify_notification_new() and internally it does a g_object_new(), gets a GObject* and returns it as a NotfiyNotification*, so when my application does the clean up, should I call a g_object_unref() on the pointer returned by notify_notification_new()?
Yes, unless the reference is "floating". Subclasses of GInitiallyUnowned use floating references; the most common use is GTK widgets.
When you create a GTK widget using a gtk_whatever_new() function, it has one reference which is marked as floating. When you add the widget to a container, the container must also hold a reference to the widget. But instead of calling g_object_ref() on the widget and increasing the reference count to 2, it "sinks" the object's floating reference and turns it into a normal reference. You could say that the container now "owns" the widget.
Then when you destroy the container, it calls g_object_unref() on the widget, and the reference count becomes zero, and the widget is destroyed. That way you're not responsible for destroying it yourself anymore.
So with normal GObjects, which usually don't go into containers, there is no transfer of ownership. You have to unreference them yourself when you're done with them.
The answer is yes, I figured it out from Gnome's page on ownership, I hope it helps someone later.
Related
Both functions of WindowedStream: .apply and .process has the same description. The only difference I've found was that: .apply receives Context whereas .proccess receives Window.
What should one consider when deciding between apply and process?
The newer process method is passed a Context, which contains the Window and other useful fields. This subsumes the apply method, which is passed the Window. There is no good reason to use apply, it has simply been retained for backwards compatibility.
I want to create an instance of an object from an assembly that implements an interface I define in my Forms app. I would create this object at app startup using Activator.CreateInstance, and keep an application-level reference to it.
At certain points during this application I want to call methods on this object without holding up the main thread using Task.Run(() => IMyObject.DoSomeWork(someList, someList2)). I just want to make a "fire and forget" void method call and I don't need to await or even register callbacks.
Will the fact that the app is running in an STA thread pose an issue? Do I have to worry about leaks or premature collection of objects I instantiate on the main thread and reference inside the task closure? I only intend to read the contents of these lists, not modify them.
No need to worry; as soon as you create the delegate, all the objects it references will be kept in memory, at least until the Task.Run exits. There's nothing that an STA thread does that changes that.
Threads don't factor into GC at all - except that all stacks for running threads contain root objects. You can cross-reference objects however you want and it won't confuse the GC.
I am using glade to make my .ui files and then using GtkBuilder I am loading that whole .ui file in my C program, so all the widgets and stuff are created from the builder files itself.
Earlier I had been creating widgets only from the code itself, hence allowing me to pass any type of data to the Callback since the second argument is a gpointer variable and I could anytime create a pointer to a custom made structure and pass any type of data to the callbacks.
But now to connect to the signals I am just using this simple function :
gtk_builder_connect_signals(builder, NULL);
where builder is a pointer to GtkBuilder.
This connects all the signals mentioned in glade file with those of function defined in the .c files without having any provision of passing user_data other than that of Widgets (which themselves can only be defined in glade.)
Can anybody tell me a solution so that I can pass any type of data to my callbacks. I don't want to leave glade since it saves lot of my time, hence I would not like to switch over to traditional way of creating widgets by code only.
An example using both g_connect_signal() and gtk_builder_connect_signals() would be helpful. In this case which one to call first to override signal connection.
You can call gtk_builder_get_object to retrieve any widget created by Glade given the widget's name. Then you can connect the widget to the signals with the usual g_connect_signal API. The drawback is that you can no longer simply "mention" signals in the glade definition.
The other way is to also use gtk_builder_get_object to get the object, but to call g_object_set_qdata to associate the necessary user data with a GQuark key known to you. Your callback can then pick up the user data from the widget using g_object_get_qdata with the same key. This has the advantage that you would still be using gtk_builder_connect_signals.
That NULL pointer you are passing in is for the user data pointer.
gtk_builder_connect_signals(builder, NULL);
^
here----------------------------------|
If you always have the same user data object then your problem is solved. If not you
will need some kind of data structure for the different user data pointers so that
each callback can find the correct one.
I checked which thread my Dispose(bool) methods get called on. When the app is running, it is always the UI thread that calls Dispose, say when clicking on the [x] to close a Form. But when I close the whole app, many Dispose methods get called on a (single) different thread. When I dump the stack trace, I see that they all get called from
System.ComponentModel.Component.Finalize().
Does that mean all my Dispose methods need to be made thread-safe? Or is WinForms guaranteeing that the UI thread won't touch these objects any more and does it also establish some kind of "happened-before" relationship between the UI thread and the one that's now finalizing?
Yes, the finalizer works on a separate thread. Usually this is no problem, because when an Object is finalized it is not reachable by any user thread (like the UI thread) anymore. So, you usually do not have to be thread-safe within your finalizer.
I have a form and several external classes (serial port, file access) that are instantiated by the form.
1) What's the simplest way to run an instance of an external class in its own thread?
2) Is the instance's thread automatically terminated when the form closes?
1) What's the simplest way to run an instance of an external class in its own thread?
Instances of classes do not "run". Methods do.
As such, you may want to look into the APM pattern and the BackgroundWorker class.
2) Is the instance's thread automatically terminated when the form closes?
It depends on how the threads were started. A thread can be a background thread or a foreground thread - the latter prevents the application from terminating.
If it's just a couple of lines of code you want to call asynchronously, probably the best way is ThreadPool.QueueUserWorkItem. See: What's the difference between QueueUserWorkItem() and BeginInvoke(), for performing an asynchronous activity with no return types needed
See if you are working with managed Environment, when an object is instantiated it will automatically dispose off if it is out of scope. The Disposal is actually taken care of by Garbage collection.
If you are using UnManaged objects, its your responsibility to close resources before making the object out of scope.
Garbage collection periodically turns on and start collecting all the objects that are out of scope. If you need to work on large objects, you can try using WeakReference class which will hold the object but also expose it for Garbage collection.
Read about WeakReference and garbage collection from here:
http://www.abhisheksur.com/2010/07/garbage-collection-algorithm-with-use.html
I hope this would help you.