RE: Does gtk have issues with STL?
On Tue, 2008-02-12 at 16:19 -0500, Vallone, Anthony wrote: You do not need to call gdk_thread_init() if you are only invoking GDK/GTK+ functions by message passing via g_idle_add() (that is, if you are not calling gdk_threads_enter()/leave()). That's interesting. g_idle_add() is thread safe without telling it to use mutex locking? Based on the docs, I've always called g_thread_init assuming I had to. This may have a complicated answer, but how does it safely manage being called by multiple threads given that it is probably accessing data shared by the threads? You have omitted from your reading (and from the extract quoted in your posting) the part of the message which said this: You can use pthreads under glib without problems. For Unix-like systems, gthreads is only a wrapper for pthreads. However, you need to call g_thread_init() to make glib (including g_idle_add()) thread safe, whether you are using gthreads or using pthreads directly. Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
Am Montag, den 11.02.2008, 18:19 -0500 schrieb Jacques Pelletier:
On February 11, 2008 05:37:54 pm Vallone, Anthony wrote:
From:
Vallone, Anthony [EMAIL PROTECTED]
To:
gtk-list@gnome.org
Myself, I avoid the enter/leave calls in favor of g_idle_add() as a
mechanism to queue all gui calls for the main event loop thread. Let
your other threads stick to performing the non-gui work, and you'll save
yourself from many headaches. (I wish someone told me that 3 years ago).
Hi,
I'm interested to know more about that. Is there some source code example
that
I can follow?
The pattern goes like this:
if (!g_thread_create (background_worker, job_data, joinable, error))
{
report_error (error);
return;
}
static gpointer
background_worker (gpointer data)
{
JobStruct *job = data; /* extract job description from data */
/* do everything you like, EXPECT touching widgets */
g_idle_add (report_progress, progress_data);
/* still do what your want, EXPECT touching widgets */
return result;
}
static gboolean
report_progress (gpointer data)
{
ProgressData *progress = data; /* extract progress from data */
MamanBar *ui = progress-ui; /* retreive UI handle */
gtk_label_set_text (GTK_LABEL (ui-progress_label), progress-text);
gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (ui-progress_bar),
progress-fraction);
/* UI has been update. Do not call this function again, unless
* new progress happend. In this case the function is re-added
* to the idle queue with g_idle_add().
*/
return FALSE;
}
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Tue, 2008-02-12 at 08:56 -0500, Lindley M French wrote: Interesting. So g_idle_add can be safely called from a different thread? Does it have to be a gthread, or will a pthread work as well? You can use pthreads under glib without problems. For Unix-like systems, gthreads is only a wrapper for pthreads. However, you need to call g_thread_init() to make glib (including g_idle_add()) thread safe, whether you are using gthreads or using pthreads directly. You do not need to call gdk_thread_init() if you are only invoking GDK/GTK+ functions by message passing via g_idle_add() (that is, if you are not calling gdk_threads_enter()/leave()). Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Does gtk have issues with STL?
Interesting. So g_idle_add can be safely called from a different thread? Does it have to be a gthread, or will a pthread work as well? I have been using pthreads with g_idle_add for a few years. It seems to work fine. Just make sure you call g_thread_init(NULL) before gtk_main(). I've added gdk_threads_enter/leave around all my calls, and so far as I can tell, everything appears to be fine now. I can say that on Solaris 9 with GTK 2.1.0 there are definitely subtle, yet serious bugs in the thread aware functionality that enter/leave offers. On a large project, it took us a few months to realize that it wasn't working. One problem in particular was that GtkTreeView updates done from an alternate thread sometimes got mangled or core dumped. We gave up on the enter/leave calls and started using g_idle_add. Random problems went away, and our design was greatly improved. However, the enter/leave bugs may have been fixed since 2.1.0. -Anthony Vallone ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Tue, 2008-02-12 at 20:24 +, Chris Vine wrote:
On Tue, 2008-02-12 at 08:56 -0500, Lindley M French wrote:
Interesting. So g_idle_add can be safely called from a different thread?
Does it have to be a gthread, or will a pthread work as well?
You can use pthreads under glib without problems. For Unix-like
systems, gthreads is only a wrapper for pthreads.
However, you need to call g_thread_init() to make glib (including
g_idle_add()) thread safe, whether you are using gthreads or using
pthreads directly. You do not need to call gdk_thread_init() if you are
only invoking GDK/GTK+ functions by message passing via g_idle_add()
(that is, if you are not calling gdk_threads_enter()/leave()).
Since I see one of your e-mails was asking for a pattern for using
g_idle_add() in C++, here is something I use. Go to the end to see the
function which actually dispatches the callback via g_idle_add().
Chris
/* Copyright (C) 2008 Chris Vine
The library comprised in this file or of which this file is part is
distributed by Chris Vine under the GNU Lesser General Public
License as follows:
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public License
as published by the Free Software Foundation; either version 2.1 of
the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License, version 2.1, for more details.
You should have received a copy of the GNU Lesser General Public
License, version 2.1, along with this library (see the file LGPL.TXT
which came with this source code package in the src/utils sub-directory);
if not, write to the Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA, 02111-1307, USA.
However, it is not intended that the object code of a program whose
source code instantiates a template from this file should by reason
only of that instantiation be subject to the restrictions of use in
the GNU Lesser General Public License. With that in mind, the words
and instantiations of templates (of any length) shall be treated as
inserted in the fourth paragraph of section 5 of that licence after
the words and small inline functions (ten lines or less in length).
This does not affect any other reason why object code may be subject
to the restrictions in that licence (nor for the avoidance of doubt
does it affect the application of section 2 of that licence to
modifications of the source code in this file).
*/
#ifndef CALLBACK_H
#define CALLBACK_H
/* These callback classes are intended for use in cases where a
callback object may need to be handed between threads and where
using sigc::slot would therefore be unsafe - this is because
sigc::slot objects representing non-static methods of a class
derived from sigc::trackable may invoke sigc::trackable functions
at slot construction and destruction which are not thread safe.
The templated helper Callback::make() functions make it trivial to
create a callback object of the correct type. A maximum of two
arguments to pass to the relevant class method is provided for -
but this can be extended indefinitely. To bind to static member
functions (or normal non-class functions), the
Callback::make_static() helper functions are also available.
The Callback::post() function is called by worker threads and will
execute a callback in the main program GMainContext loop.
*/
#include glib/gmain.h
#include iostream
#include ostream
inline void write_error(const char* message) {
std::cerr message;
}
namespace Callback {
/* The following Callback class is the interface class that users will
generally see, and is suitable for passing by void*, which if using
glib and/or gthreads and/or pthreads is almost certain to happen at
some stage.
Because of the class's intended usage, Callback::dispatch() (and
Callback::operator()()) return void. The Callback class could be
templated to provide a return value, but that would affect the
simplicity of the interface, and if a case were to arise where a
result is needed, an alternative is for users to pass an argument
by pointer (or pointer to pointer) rather than have a return value.
*/
class Callback {
public:
// because we will usually be calling through a base class pointer,
// it would be more natural to invoke the call back through a normal
// member function rather than by operator()()
virtual void dispatch() const = 0;
// but for those who want it
void operator()() const {dispatch();}
virtual ~Callback() {};
};
template class T class Callback0: public Callback {
public:
typedef void (T::* MemFunc)();
private:
T* obj;
MemFunc func;
public:
void dispatch() const {(obj-*func)();}
Re: Does gtk have issues with STL?
a nice discussion (with examples) of all this here: http://irrepupavel.com/documents/gtk/gtk_threads.html and, g_idle_add() is indeed thread safe. it was written that way, on purpose. there's really no mystery to a function being thread-safe or not, either it was written intended to be, or it wasn't. gtk generally wasn't, so it isn't. not sure why you think that it is accessing data shared by threads. it does exactly one thing, take the arguments provided by the caller, and place a call to the specified function on the main loop queue. i don't see where it needs to access any common memory. (could easily have a look at the function itself, i suppose.) and, whether you gain an improvement in performance by removing your mutex calls, that depends on how much multiple calls to g_idle_add() is actually colliding. if they never collide, you won't notice any improvement. if you call g_idle_add() 100X/second, you will definitely see an improvement. best way to answer this is run your own benchmarks and assess yourself, there's really no other way to tell. cheers, richard On Feb 12, 2008 10:19 PM, Vallone, Anthony [EMAIL PROTECTED] wrote: You do not need to call gdk_thread_init() if you are only invoking GDK/GTK+ functions by message passing via g_idle_add() (that is, if you are not calling gdk_threads_enter()/leave()). That's interesting. g_idle_add() is thread safe without telling it to use mutex locking? Based on the docs, I've always called g_thread_init assuming I had to. This may have a complicated answer, but how does it safely manage being called by multiple threads given that it is probably accessing data shared by the threads? Also, will I get any performance improvement if I remove it? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Does gtk have issues with STL?
You do not need to call gdk_thread_init() if you are only invoking GDK/GTK+ functions by message passing via g_idle_add() (that is, if you are not calling gdk_threads_enter()/leave()). That's interesting. g_idle_add() is thread safe without telling it to use mutex locking? Based on the docs, I've always called g_thread_init assuming I had to. This may have a complicated answer, but how does it safely manage being called by multiple threads given that it is probably accessing data shared by the threads? Also, will I get any performance improvement if I remove it? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Does gtk have issues with STL?
Hi,
I'm interested to know more about that.
Is there some source code example that I can follow?
--
JP
The pattern that Mathias supplied is a good one for C. Since we are
talking STL, here is a rough sketch of the pattern that I follow for
C++. Of course, there are many good ways to do it, and you should
change this pattern to match your requirements. For example, you may
want a thread-safe singleton task queue to handle batches of tasks in
one event. But don't forget the golden rule of event loop based gui
programs: To keep the gui responsive to the user, each event needs to be
handled quickly.
-Anthony Vallone
//
// call this before gtk_main to tell glib that you are multithreaded.
g_thread_init(NULL);
// define a task interface
class GuiTask {
public:
virtual void process() = 0;
virtual ~GuiTask() {}
};
// implementations of the task interface to suit your needs
class LongComputationResultsX : public GuiTask {
public:
LongComputationResultsX(results and handlers) {...}
virtual void process() {use results and handlers to update the widgets
and state}
virtual ~LongComputationResultsX() {...}
private:
results and handlers
};
class LongComputationResultsY..., Z..., etc...
// this will get called in the main event loop thread
extern C gboolean idleTaskFunction(gpointer userData)
GuiTask* task = (GuiTask*)userData;
task-process();
delete task;
return false;
}
// when the worker thread has something to supply to the main thread,
// call this from the worker thread
g_idle_add(idleTaskFunction, new LongComputationResultsX(stuff));
//
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Does gtk have issues with STL?
Myself, I avoid the enter/leave calls in favor of g_idle_add() as a
mechanism to queue all gui calls for the main event loop thread. Let
your other threads stick to performing the non-gui work, and you'll save
yourself from many headaches. (I wish someone told me that 3 years ago).
BTW, I always use STL and GTK+ together. Never had a problem.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Lindley M French
Sent: Monday, February 11, 2008 5:23 PM
To: gtk-list@gnome.org
Subject: Re: Does gtk have issues with STL?
I had already figured out that widgets had to be created in the main
thread, or else the event loop wouldn't handle them. I did not realize
that one had to be careful with updating widgets as well! That explains
a few things.
So gdk_threads_enter() should be called around data updates. But is that
called automatically in default signal handlers, or do I need to put it
there myself as well? It feels odd locking only one thread explicitly.
Also, may I assume that calls made in the thread containing the event
loop don't need this protection?
- Original Message -
From: Paul Davis [EMAIL PROTECTED]
Date: Monday, February 11, 2008 4:49 pm
Subject: Re: Does gtk have issues with STL?
On Mon, 2008-02-11 at 15:45 -0500, Lindley M French wrote:
I suspect these are merely symptoms of some other corruption,
but I can't seem to find it.
with a 99.872% confidence level, i can confirm your belief.
I'm using pthreads with this; nothing complex, and I think I
have everything mutex'd, but it did make me wonder: Does GTK use
gthreads internally, and is there any issue with using gthreads and
pthreads at the same time?
if you don't understand the answer to this already, it suggests that
it may be unwise for you to be using threads at all.
the use of threads in GUI toolkits that originated in the X Window
worldis generally quite difference than the use of it with GUI
toolkits that originated in the win32 world. in particular, the
general rule in GTK
is:
EITHER make GTK/GDK/X11 calls from a single thread only OR use
GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
call(s).
googling will turn up plenty of refs to this stuff.
Also: Is it bad to emit a signal while in a signal handler
callback? In this case I'd like to make sure a scrollbar value- update
takes place every time a bounds-update does.
in general, its not a problem. there are some specific instances where
it can be an issue.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
I had already figured out that widgets had to be created in the main thread, or
else the event loop wouldn't handle them. I did not realize that one had to be
careful with updating widgets as well! That explains a few things.
So gdk_threads_enter() should be called around data updates. But is that called
automatically in default signal handlers, or do I need to put it there myself
as well? It feels odd locking only one thread explicitly.
Also, may I assume that calls made in the thread containing the event loop
don't need this protection?
- Original Message -
From: Paul Davis [EMAIL PROTECTED]
Date: Monday, February 11, 2008 4:49 pm
Subject: Re: Does gtk have issues with STL?
On Mon, 2008-02-11 at 15:45 -0500, Lindley M French wrote:
I suspect these are merely symptoms of some other corruption,
but I can't seem to find it.
with a 99.872% confidence level, i can confirm your belief.
I'm using pthreads with this; nothing complex, and I think I
have everything mutex'd, but it did make me wonder: Does GTK use
gthreads internally, and is there any issue with using gthreads
and pthreads at the same time?
if you don't understand the answer to this already, it suggests
that it
may be unwise for you to be using threads at all.
the use of threads in GUI toolkits that originated in the X Window
worldis generally quite difference than the use of it with GUI
toolkits that
originated in the win32 world. in particular, the general rule in GTK
is:
EITHER make GTK/GDK/X11 calls from a single thread only OR
use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
call(s).
googling will turn up plenty of refs to this stuff.
Also: Is it bad to emit a signal while in a signal handler
callback? In this case I'd like to make sure a scrollbar value-
update takes place every time a bounds-update does.
in general, its not a problem. there are some specific instances where
it can be an issue.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Mon, 2008-02-11 at 15:45 -0500, Lindley M French wrote:
I suspect these are merely symptoms of some other corruption, but I can't
seem to find it.
with a 99.872% confidence level, i can confirm your belief.
I'm using pthreads with this; nothing complex, and I think I have everything
mutex'd, but it did make me wonder: Does GTK use gthreads internally, and is
there any issue with using gthreads and pthreads at the same time?
if you don't understand the answer to this already, it suggests that it
may be unwise for you to be using threads at all.
the use of threads in GUI toolkits that originated in the X Window world
is generally quite difference than the use of it with GUI toolkits that
originated in the win32 world. in particular, the general rule in GTK
is:
EITHER make GTK/GDK/X11 calls from a single thread only OR
use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
call(s).
googling will turn up plenty of refs to this stuff.
Also: Is it bad to emit a signal while in a signal handler callback? In this
case I'd like to make sure a scrollbar value-update takes place every time a
bounds-update does.
in general, its not a problem. there are some specific instances where
it can be an issue.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
For the moment, getting Linux to work seems like more trouble than its worth; so Valgrind is out for now. I'll revisit that option tomorrow, when someone who's used GTK on Linux before will be around. I've set Visual Studio's debug level to 3, and I'm not getting any warnings that way. On level 4 I get unreferenced formal parameter all over the place, and a few others, but nothing that looks important. Although behavior is still somewhat inconsistent, I have found one thing which seems to cause or remove the problem depending on its inclusion: gtk_button_set_label(GTK_BUTTON(radiobutton),Dummy); radiobutton is, naturally, a GtkRadioButton. This function gets called a number of times, to change the button's label depending on what's being shown in the associated window. (The radio button's purpose is to select which window gets the current input.) The Dummy text isn't what's supposed to go there, but the problem occurs even with it. The GTK_BUTTON typecast does not produce an error. Another place where a similar issue appears to hold is: gtk_list_store_set(store, last, 0, Dummy, -1); Including this causes issuessometimes it'll say gsignal.c 650 emmission_pop should not be reached, aborting (or something like that), sometimes it'll say there's a disparity between the list view and the store. It *is* okay to update the store after it's been attached to the tree view, isn't it? Or do I need to stick a mutex in the view redraw function? I suspect these are merely symptoms of some other corruption, but I can't seem to find it. I'm using pthreads with this; nothing complex, and I think I have everything mutex'd, but it did make me wonder: Does GTK use gthreads internally, and is there any issue with using gthreads and pthreads at the same time? Also: Is it bad to emit a signal while in a signal handler callback? In this case I'd like to make sure a scrollbar value-update takes place every time a bounds-update does. - Original Message - From: Chris MacGregor [EMAIL PROTECTED] Date: Friday, February 8, 2008 3:12 pm Subject: Re: Does gtk have issues with STL? If it's not completely impractical, you might consider debugging on Linux a bit - there you can use Valgrind (probably worth the effort to port it over just for that, if it takes less than several days), and if you're multi-threaded, Helgrind (get the very latest release) as well might help you quite a bit. Sounds like you're dealing with race conditions (or could be memory corruption, of course). Valgrind/Helgrind could find your problems. On 02/08/2008 11:50 AM, Lindley M French wrote: I'd love to think it's my own source code. However, the randomness of the errors I get (or sometimes, don't get) prevents me from easily tracking them down. Is there some randomization at work inside GTK? I can't see why there would be, but it's the only thing I can think of that would cause the same binary code to produce different behavior on successive runs. And I can't form a test case until I know what triggers the crash, because otherwise I won't know if absence of a crash is evidence that the test is working or not. If I had GTK source code to break on, it would make things easier. However, the distribution I'm using didn't come with source, and my attempts to compile the source releases I've found have so far been unsuccessful. Bloody Windows. - Original Message - From: Murray Cumming [EMAIL PROTECTED] Date: Friday, February 8, 2008 1:26 pm Subject: Re: Does gtk have issues with STL? On Fri, 2008-02-08 at 10:44 -0500, Lindley M French wrote: The instability I was seeing before might have been due to my use of an STL map to maintain my list of available windows. Is this a known issue, or should I be looking elsewhere? I'm suspicious because several of the errors I've gotten (they're different each time, even if I don't recompile) have related to reference counting errors. Since STL maintains some internal state, there might be something going on there. No, this doesn't make any sense. You have probably made errors in your own source code. You should try valgrind and/or try to reduce it to a simple test case. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Mon, 2008-02-11 at 17:08 -0700, Michael L Torrie wrote:
Paul Davis wrote:
EITHER make GTK/GDK/X11 calls from a single thread only OR
use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
call(s).
This seems to crop up all the time. From what I recall, the use of
threads of any kind with GTK on Win32 is not supported,
win32 is sort of thread-safe but all events for a given window must be
handled by the thread that created the window. its an odd system if you
come from X11. this is true whether you use GTK or native win32 APIs.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
Paul Davis wrote:
EITHER make GTK/GDK/X11 calls from a single thread only OR
use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
call(s).
This seems to crop up all the time. From what I recall, the use of
threads of any kind with GTK on Win32 is not supported, even with the
ENTER/LEAVE calls around every GTK/GDK call. The only way to use
threads and GTK in win32 is to do the g_idle_add thing to trigger a
callback from the thread.
Usually trying to use threads in GTK in win32 doesn't cause memory
corruption, though, so that's a separate problem, I think.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Mon, 11 Feb 2008, Paul Davis [EMAIL PROTECTED] wrote : the use of threads in GUI toolkits that originated in the X Window world is generally quite difference than the use of it with GUI toolkits that originated in the win32 world. Actually I never noticed the difference, because my exposure to Win32 was through Borland's VCL library, which is non-thread-safe in similar ways to GTK. The all GUI calls in one thread rule applied there too. But being more accustomed to embedded code for systems with no OS and only a minimal scheduler, I don't tend to use threads anyway. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On February 11, 2008 05:37:54 pm Vallone, Anthony wrote: From: Vallone, Anthony [EMAIL PROTECTED] To: gtk-list@gnome.org Myself, I avoid the enter/leave calls in favor of g_idle_add() as a mechanism to queue all gui calls for the main event loop thread. Let your other threads stick to performing the non-gui work, and you'll save yourself from many headaches. (I wish someone told me that 3 years ago). Hi, I'm interested to know more about that. Is there some source code example that I can follow? -- JP ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Does gtk have issues with STL?
The instability I was seeing before might have been due to my use of an STL map to maintain my list of available windows. Is this a known issue, or should I be looking elsewhere? I'm suspicious because several of the errors I've gotten (they're different each time, even if I don't recompile) have related to reference counting errors. Since STL maintains some internal state, there might be something going on there. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Fri, 2008-02-08 at 10:44 -0500, Lindley M French wrote: The instability I was seeing before might have been due to my use of an STL map to maintain my list of available windows. Is this a known issue, or should I be looking elsewhere? I'm suspicious because several of the errors I've gotten (they're different each time, even if I don't recompile) have related to reference counting errors. Since STL maintains some internal state, there might be something going on there. No, this doesn't make any sense. You have probably made errors in your own source code. You should try valgrind and/or try to reduce it to a simple test case. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
I'd love to think it's my own source code. However, the randomness of the errors I get (or sometimes, don't get) prevents me from easily tracking them down. Is there some randomization at work inside GTK? I can't see why there would be, but it's the only thing I can think of that would cause the same binary code to produce different behavior on successive runs. And I can't form a test case until I know what triggers the crash, because otherwise I won't know if absence of a crash is evidence that the test is working or not. If I had GTK source code to break on, it would make things easier. However, the distribution I'm using didn't come with source, and my attempts to compile the source releases I've found have so far been unsuccessful. Bloody Windows. - Original Message - From: Murray Cumming [EMAIL PROTECTED] Date: Friday, February 8, 2008 1:26 pm Subject: Re: Does gtk have issues with STL? On Fri, 2008-02-08 at 10:44 -0500, Lindley M French wrote: The instability I was seeing before might have been due to my use of an STL map to maintain my list of available windows. Is this a known issue, or should I be looking elsewhere? I'm suspicious because several of the errors I've gotten (they're different each time, even if I don't recompile) have related to reference counting errors. Since STL maintains some internal state, there might be something going on there. No, this doesn't make any sense. You have probably made errors in your own source code. You should try valgrind and/or try to reduce it to a simple test case. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
