On 08/11/2013 09:41 PM, Gavin Lambert wrote:
texttoprint +=
"About to run a number of c++ functions\nand display the
results\n";
m_refTextBuffer->set_text(texttoprint);
m_textview.set_buffer(m_refTextBuffer);
This is all fine right up until that last line, which contains a subtle (but
important) bug.
Thanks Gavin I'm glad that your message suggests that I may have done
something right. I have tried. I appreciate your pointing out about
bugs in gtkmm. I'm sure with my investigation I'll eventually learn
about the bugs and try to assist in the debugging of it, as well as
other compoentns that fall short.
GTK widgets (and other UI elements of most other GUI frameworks) are
typically not merely thread-unsafe (as most objects are by default: can be
called from any thread provided that they can be guaranteed to not be called
concurrently) but actually thread-bound (can be called only from one
specific thread, typically the one that created them, or a designated "main
thread").
I thought I was communicating in the main thread that created it. With
all the complexity of using the gui, it might be a feat that I'm
actually able to add a couple of lines to an example and achieve the
needed effect, in spite of the tool having known bugs.
I'll keep everything that you mention in mind while I'm programming and
try to identify any glitches that I experience and figure out how to
report it to the community, or how to use the bug work around that might
already be distributed.
It is therefore not permitted to touch m_textview from any thread other than
the main thread, which that last line is doing. (And then since this is
assigning a reference to the buffer, it then becomes unsafe to further
modify that buffer later in the worker thread.)
In short, while this might appear to work on your machine for this contrived
example, if you run it enough times in enough different environments and
with different workloads (eg. more frequent text updates) it's very likely
to either crash or exhibit other strange behaviour. So don't do that.
Others have already pointed you at the correct solutions, and as I am not
sufficiently practiced at GTK myself to give you a precise example I can
only reiterate what those others have said.
I thought I was using what others has pointed out. The only components
that I thought I wasn't using is the parts that say have difficult or
impossible it is. There was some code examples that were presented that
either dimmed and became non-responsive, or never gave an update until
the application had finished, which weren't usable. I couldn't use
those components.
From your description of what you're trying to do it seems likely that
carrying out the "actual work" on a separate thread is indeed the correct
thing to be doing. But you can't just play with GUI objects outside of the
GUI thread. You need to use some method to convey data from one thread to
another (eg. an explicitly thread-safe queue) combined with some way to get
the main thread to wake up and do some processing (eg. Glib::Dispatcher or a
timeout handler).
In your case, I would recommend using a std::queue of text-to-be-added
protected by a mutex (to make it thread-safe) combined with a
Glib::Dispatcher callback that triggers the main thread to dequeue text and
add it to the textview.
I'll respect your suggestions just as well as I hoped I was respecting
all the other suggestions, and still trying to have some representation
of the needed output (a gui screen update). I'll try to figure out what
you're saying and find a way to implement it without actually breaking
the operation. If I add other lines and it stops working, I'd have to
come back to what is actually working.
At present, I don't know where to begin, except for what I'm already
doing, continuing to study and read everything that appears in the
maillist... the things in the threads that I create as well as all the
other threads, which are not that easy for me to follow. But I'm reading
and trying to comprehend all the messages.
(Though again as others have pointed out if your "actual work" is merely
calling a console application or performing file/network/pipe I/O then you
may want to try using the asynchronous I/O helpers instead, to avoid the
extra thread.)
You may not know much about my actual work. Most of the lines I used in
this message thread was a line that goes into a function called sleep.
Then appends some text to the gui window. I took a function out of my
tens of thousands of lines of code that I have been writing over the
past 25 years (of which I mentioned had only been represented once) and
you are using that to say most of my work. The user as me to post an
example with less than 50 lines So I created something to go out and
fix some output. Then I wrote that to the gui window, of which I
thought was the main thread. I believe you make a big mistake when you
refer to most of my work. I hope to have some way to append text to a
gui window regardless where a function such as possibly (sleep()) might
get the text from. Most of the code that I was given used the function
(sleep()). If it gave a return value. Could I update the screen with
that return value? I created text after the operation got back from the
function sleep() as it that was the return value and updated the gui
screen. That is the best representation of my actual work. I thought I
was complying in every way with the suggestions that I was getting from
the members.
Multithreading is hard (to get correctly, at least -- it's easy to do it
wrong). Asynchronous is less hard but still confusing until you get used to
the ideas. It may be worthwhile for you to read up on both of these
concepts independently of GTK, then read how they apply to GTK, then finally
how they apply to your applications. You're not going to find a quick and
easy solution -- or at least if you do find one and try to use it without
properly understanding it, you're letting yourself in for a world of hurt.
I'll take up your advise just as well as I have been trying to take up
the advise of everyone. I hope it's clear that I haven't stopped
working and won't. If I learn how to actually implement something
different based on your words that works, I'll come back and post it.
I thank you for the comments. But again, your tone appears to suggest
that I'm not trying to comply with what everyone is saying. I believe
mainly fall short on the component where I go into details trying to
explain what I'm trying to do, and almost everyone is telling me that I
talk to much. I'll try to compile and use the suggestions that I'm
getting, but I can't use the components that immediately fails. I post
something that isn't immediately failing, and am told to do something
different, of which I don't understand. If you posted an example of the
difference that you're referring to I'd actually test it and tell you
the results. If it doesn't update a gui screen, it wouldn't be usable.
But I'd test it just like I'm trying to test everything else.
I thought that I was following Kjell's suggestion to element that things
that I wouldn't be using and use the important one liner that he
presented. I'm still working with Kjell's example, trying to figure out
how to eliminate everything and add just one blank slate and built from
there. I guest as you're suggestion I got it wrong in my manner of
eliminating everything by taking the simplest code that only had one
thing (the button from the hello world tutorial). I made one change and
thought I was adding Kjell's line and following to the letter what I was
presented with.
I don't know how to follow the suggestions any closer that what I'm doing.
Since you think everyone is telling me something different, I'll follow
your suggestion and reread the thread and keep studying the thread to
see where I'm going wrong. I understand I might be missing something,
but at present if I can't see it, I can only report on the results and
appreciate any further comments.
Kjell said in his message, that everything was already there in the
documentation, just not an actual example (a few days ago). So I went
back and did as you appear to be suggesting, spent sleepless nights
since, reading and studying and actually using what is there.
You appear to be telling me to study and use gtk rather than gtkmm. I
fear that if I did that and tried to post something, I might be
admonished even more for not using gtkmm which this forum is about, and
reinventing the wheel. I'll take your advise and start studying gtk,
but I'll be very leery to start creating my own interface when you
describe it so complicated that it's broken in gtkmm which has been in
the development for a number of years.
I hope that I presented my efforts to comply with everything that I'm
presented with, of which I can understand, and continue to work at the
same time, and share what I have come up with at this point, based on
taking in everything that is being presented. I can't use the parts
that I don't understand. I won't stop studying, as you have suggested.
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
