Las limitaciones
Care is required when writing programs based on gtkmm using multiple threads of execution, arising from the fact that libsigc++, and in particular sigc::trackable, are not thread-safe. That's because none of the complex interactions that occur behind the scenes when using libsigc++ are protected by a mutex or other means of synchronization. 1
- 27.1.1. Las reglas
27.1.1. Las reglas
Esto requiere que se observen una cantidad de reglas cuando escribe programas de múltiples hilos usando gtkmm. Estas se exponen abajo, pero un punto a destacar es que se requiere cuidado adicional cuando deriva clases de sigc::trackable, porque los efectos no son intuitivos (consulte particularmente los puntos 4 y 5 debajo).
-
Use Glib::Dispatcher para invocar las funciones de gtkmm desde hilos de trabajo (esto se explica con má detalle en la próxima sección).
-
Un objeto sigc::signal debe considerarse propiedad del hilo que lo creó. Solo ese hilo debe conectar un objeto sigc::slot al objeto de la señal, y solo ese hilo debe llamar a emit() u operator()() sobre la señal, o anular cualquier objeto sigc::slot conectado. Sigue (junto a otras cosas) que cualquier objeto de señal proporcionado por un widget de gtkmm solo se opere en el hilo principal de la IGU y cualquier objeto que derive de sigc::trackable con métodos no estáticos referenciados por «slots» conectados al objeto de señal solo deben destruirse en ese hilo.
-
Cualquier objeto sigc::connection solo debe considerarse propiedad del hilo en el que se llamó al método que devuelve el objeto sigc::connection. Solo ese hilo debe llamar a métodos de sigc::connection sobre el objeto.
-
A sigc::slot object created by a call to sigc::mem_fun() which references a method of a class deriving from sigc::trackable should never be copied to another thread, nor destroyed by a different thread than the one which created it.
-
Si un objeto de clase particular deriva de sigc::trackable, solo un hilo debe crear objetos sigc::slot representando cualquiera de los métodos no estáticos de la clase llamando a sigc::mem_fun(). El primer hilo que cree un «slot» semejante debe considerarse dueño del objeto relevante con el propósito de crear más «slots» referenciando a cualquiera de sus métodos no estáticos que usan esa función, o anulando aquellos «slots» desconectándolos o destruyendo el objeto «trackable».
-
A pesar de que glib en sí es segura para hilos, cualquier envoltorio de glibmm que use libsigc++ no lo será. Entonces por ejemplo solo el hilo en el bucle principal debe llamar a Glib::SignalIdle::connect(), Glib::SignalIO::connect(), Glib::SignalTimeout::connect(), Glib::SignalTimeout::connect_seconds para ese bucle principal, o manipular cualquier objeto sigc::connection que devuelvan.
The connect*_once() variants, Glib::SignalIdle::connect_once(), Glib::SignalTimeout::connect_once(), Glib::SignalTimeout::connect_seconds_once(), are thread-safe for any case where the slot is not created by a call to sigc::mem_fun() which represents a method of a class deriving from sigc::trackable.
These interactions arise from the fact that, amongst other things, a class inheriting from sigc::trackable will, via that inheritance, have a std::list object keeping track of slots created by calls to sigc::mem_fun() representing any of its non-static methods (more particularly it keeps a list of callbacks which will null the connected slots on its destruction). Each sigc::slot object also keeps, via sigc::slot_rep, its own sigc::trackable object to track any sigc::connection objects which it needs to inform about its demise, and also has a function to deregister itself from any sigc::trackable on disconnection or destruction. sigc::signal objects also keep lists of slots, which will be updated by a call to their connect() method or calls to any sigc::connection object relating to such a connection.