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

[Murray Cumming <murrayc murrayc com>]

On Thu, 2005-06-16 at 07:22 -0500, Bob Caryl wrote:
> Paul Davis wrote:
> 
> >what are you thinking? this has nothing to do with threads. it doesn't
> >even have a *lot* to do with language, except for the fact that you
> >can't use a non-static C++ member function as a C callback.
> >
> Evidently I have failed to make clear the circumstances surrounding this 
> situation.
> 
> The callback function involved is one that opens a resource file (like 
> an image source) to load its content into a GtkHTML widget when that 
> widget issues a "url-requested" signal.   This widget would have been 
> embedded into a scrolled_window container within a Gtk::Window.  The 
> callback function for the "url-requested" would need to have access to 
> information within the derived Gtk::Window class itself to be able to do 
> its job.
> 
> 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.
> 
> *That* is what I was thinking, Paul.  If my concerns in this regard are 
> misplaced I would hope you guys would point out *why*.

Again, please look at the various *SignalProxy classes, as suggested so
you can use sigc++ slots and not worry about this state information.
Threads still seem to have nothing to do with this.

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