Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro

[Murray Cumming <murrayc murrayc com>]

On Thu, 2005-06-16 at 08:01 -0500, Bob Caryl wrote:
> Lars Luthman wrote:
> 
> >On Thu, 2005-06-16 at 07:22 -0500, Bob Caryl wrote:
> >  
> >
> >>I had originally intended to write my help display routine as part of a 
> >>dynamic library intended for use by my applications.  If I use a global 
> >>function in this setting it would be entirely possible that multiple 
> >>applications and/or threads in the same application could try to call 
> >>such a global function simultaneously (or nearly simultaneously), 
> >>thereby giving indeterminate results.
> >>    
> >>
> >
> >Why would a global function be less thread safe than a member function?
> >As long as you're not using any global or static function variables
> >(which you also could do in a member function) I don't see how there is
> >a difference.
> >
> >  
> >
> I'm an old windows programmer (and therefore relatively new to linux GUI 
> programming), and so I'm assuming that dynamically loaded libraries work 
> the same way under linux as they do under windows:
> 
> If an application (or thread within an application) instantiates an 
> object, it gets its own exclusive copy of that object (complete with all 
> the data used by such an object).  If, on the other hand, an application 
> (or thread), uses a global function and/or global data from within a 
> dynamically loaded library that is subject to such use by other 
> applications and/or threads, it is possible that simultaneous accesses 
> could happen.  In the case of my callback, two applications could be 
> trying to load data into the SAME GtkHTML widget at the same time and 
> thereby would be sharing ONE GtkHTMLStream handle.

This would only be true if it was shared (static) memory. Obviously 2
applications don't share the same widget, or every label would contain
the same text in every window in application.

> If my understanding of how dynamically loaded libraries work under 

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com