Re: Gnome/Gtk and thread safety

[otaylor redhat com]

"Ryan C. Gordon" <icculus lokigames com> writes:

> > What specific uses do you envision for a threaded GUI framework?
> 
> I envision a hoard of bad Windows programmers coming over and writing GTK+
> applications, and expecting their GUI framework to be thread safe.

I'm afraid if a bad programmer is writing threaded apps, it probably
doesn't matter what they are programming in; the result is not
going to be pretty.
 
> Yes, it will happen. No, it's not a bad thing. Why not make sure GTK is
> robust enough to handle thread safety in the first place? This is twice as
> important when porting Windows applications to GTK...believe me, I've had
> my nightmares with this...you don't want to change the basic design of the
> app any more than you need to. Changing what threads are doing what is a
> BIG design change, and would be necessary to keep all GUI calls in one
> thread.

While I don't have an exact handle on understanding threaded
programming on Windows (references? good books on the subject?), I'm
rather doubt we can present a 100% compatible model for GTK+. (if
that would be a good idea.)

To my understanding of threaded GUI programming on Windows, it is
fairly interwoven with the fact that the lowlevel drawing calls are
essentially system calls.
 
> I don't think it's wise to say "it's bad coding practice."  Well, of
> course it is.  But we need to focus on what is COMMON coding practice, and
> coders are sooner or later going to expect to be able to use this.
> 
> ...and making something thread safe is never a bad idea, is it?

Well, it can be if:

 - It reduces stability (possible especially when dealing with portability
   to a lot of platform)
 
 - It seriously hurts perforamnce.

 - It makes non-threaded programming more difficult.

 - It encourages people to write apps that then turn out to be 
   buggy either because of app problems, or because of limiations
   in the "safety" of the thread safety.

Increasing the amount of automatated thread safety in libgdk/libgtk is
definitely not 2.0 material - it could conceivably be a goal for 2.2
or 2.4. (At this point there is some idea 2.2 may be a fairly short
term, highly compatible release with 2.0.)

Regards,
                                        Owen