Hello. Your arguments may be valid (or not, that's not the point here), but:
- PyGTK just wraps Gtk+, we should _not_ change gtk+ API semantics,
because having a similar API between PyGTK and Gtk+ is a feature we
should preserve for people that like Python just for prototyping and
later on convert their projects to C, or people converting legacy C
programs to Python. Any problem with threads and signal handlers should
be discussed at gtk-devel list, not here.
- Both PyGTK and Gtk+ _must_ keep API/ABI compatibility with all
previous versions. If what you propose is not API/ABI compatible, you
have to wait for Gtk+ 3.0, which is not even planned right now, so...
Keep this in mind before deciding to continue these discussions.
Best regards.
On Mon, 2005-01-24 at 09:33 +0100, Antoon Pardon wrote:
> On Fri, Jan 21, 2005 at 09:44:46AM -0500, Dave Aitel wrote:
> > Honestly, you save yourself days of debugging if you stick to a "GUI
> > thread" and have all real work done in other threads. This requires a
> > GUI Thread "queue" that you have it clean when it gets a chance. This is
> > how CANVAS works, and we work on anything from *BSD to Windows this way. :>
> >
> > Just my opinion, but if you find yourself doing a lot of
> > thread_enter()/thread_leave(), you're guaranteed to introduce thousands
> > of tiny annoying deadlocks.
> >
> > -dave
> >
>
> Well it's not a matter of doing my self a favor but a matter of correct
> information and a matter of pygtk not making things more complicated as
> they should.
>
> 1) The correct information part is because I'm thinking about writing
> a tutorial on using threads with pygtk.
>
> 2) I think gui-programs with threading are already complicated enought,
> without the librarry introducing extra complications. So I ask for
> the possibility that signal handlers wouldn't be embedded in a
> gtk.threads_enter and get.threads_leave pair
>
> My arguments are as follows. There are two possibilities if you
> use threading with pygtk. Either you arrange your code that
> gtk.gdk call is done from the main thread or you don't.
> In the first case the embedding does no harm but is unneeded.
> In the second case the embedding may be a safe guard in simple
> examples but in general is a nuissance. For examples it complicates
> code if you have functions that can be called from the gtk as
> well as from other threads.
>
> In my first attempt to write a threaded program I ended up
> doing a gtk.threads_leave() call as my first statement in
> the On_Delete signal handler because otherwise the program
> would blok when I wanted to end it.
>
> So in the end embedding signal handlers between a gtk.threads_enter
> and get.threads_leave pair in general make things more difficult
> instead of making them easier so I think programmers should have
> at least the possibility to turn it off.
>
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
