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

[Paul Davis <paul linuxaudiosystems com>]

> 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.
> 
> If my understanding of how dynamically loaded libraries work under 
> linux, please disabuse me of my notions.

it all depends on the design of the library. good libraries (i.e. more
than 90% of them) have no global or function-scope static variables. if
they require state, they provide some kind of init function that the
caller has to invoke before doing anything (consider gtk_init()). if
they require this state for thread-safety, they generally require you to
pass some kind of object returned by the init to each call.

if there is a library function that gives you, say, a new GtkHTML
widget:

	GtkWidget* browser = gtk_html_new (...);

then there is 99.5% certainty that the object you have created is
unique. nothing else will access it unless you give them the address
stored in "browser" (or they do a pointer walk, but thats another
story). 

now of course, if the library has a function like this:

	GtkWidget* browser = gtk_html_get_the_one_instance();

then you have a different issue. If the docs don't state that you can
use the instance from multiple threads simultaneously, then you should
get a new library.

as murray said, you apparently were not confused by this with MFC and
win32 DLL's - why the confusion with Linux.

non-thread-safeness in a library is not because its a library or
dynamically linked - its because the library is badly written and/or
designed. true on win32, true on *nix. its unfortunate if your
experiences on windows have led you to think otherwise.

oh, and finally. X Window-based GUI toolkits are generally *not* thread
safe, unlike the stuff on win32. there is always a trade off with this
question: if you make things thread safe, there is real cost for the
single-GUI-thread case; if you make things non-thread safe, there is ral
cost for the multi-GUI-thread case. win32 took one path, X Window has
taken the other. this means that even though the library problems you
are imagining are not actually real, the issue of doing GUI work from
multiple threads with *any* X Window toolkit (GTK, Qt, FLTK etc) need to
be carefully thought through. The solutions are not hard, but they
require a comprehensive understanding of the issues, and a consistent
approach to program design Google for "GTK threads multiple" and you'll
find a smattering of posts, some of them even from me :)

--p