Re: Error that aborts a running GTK application using threads.

["Mario Segura" <masegurita gmail com>]

Hi,

So, I will add the following line to my GUI.h file:

---
Glib:Mutex mutex;
---

and then in the GUI.C++, i will call
--
Glib::Mutex::Lock lock (mutex);
--

everytime i need to access a share variable/widget using secondary threads (not the main)


Is this the way to proceed to have syncronization between threads?
I am little bit confused about mutex.


Thanks,

Mario Segura S.

On 4/30/06, Paul Davis <pjdavis engineering uiowa edu> wrote:

Mario Segura wrote:

> Hi,
>
> I got the following message, that aborts my application:
>
> -----------------------------
> (principalgui:2792): Gtk-WARNING **: gtktextview.c:4221: somehow some
> text lines  were modified or scrolling occurred since the last
> validation of lines on the s creen - may be a text widget bug.
>
> Gtk-ERROR **: file gtktextview.c: line 4222 (gtk_text_view_paint):
> should not be  reached
> aborting...
> Aborted
> -----------------------------
>
>
> This happens randomly when a thread is running and it tries to use a
> text buffer to write some lines. Some times the thread can write
> almost all the lines, sometimes in the first line the application
> crashes, it don't depend in the number of lines the thread writes. I
> use mutex every time i want to write a line in the buffer.
>
> C++ code that randomly produces the error used by a thread. variable
> "line" contains the text that will be added.
>
> ------------
>     Glib::Mutex mut;
>     mut.unlock ();
>     consolabuffer->insert_at_cursor(line);//Agrega al buffer el texto
> recibido
>     mut.lock();
> ------------
>
> Any idea how i could prevent this error without avoing the use of the
> buffer?
>
> Thanks,
>
>
> --
> Mario Segura S.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>gtkmm-list mailing list
>gtkmm-list gnome org
>http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
Sounds like a synchronization issue.

Is there any reason that your calls to Lock and Unlock are reversed?
Generally when using a mutex, you make sure its locked while you access it.

And trying not to make to much of the four lines, but if you're
instantiating a new mutex everytime you enter the method that does the
writing, then you aren't going to have synchronization.

The other guys might be able to tell you more about the threaded
architecture of Gtkmm, but I've always been under the impression that
accessing your widgets from anything outside the thread in the main run
loop is a bad idea.

I would implement this using a shared class instance that contains a
mutex and a string buffer.  Then instead of having your worker thread
write directly to the TextArea widget, you'd write to the shared
instance.  And in your Gtk thread, you could connect to the on idle
signal and poll the shared instance, and update the widget accordingly.

Paul Davis

-- 
Mario Segura S.