On Wed, 2010-07-07 at 08:00 +0800, Jason Heeris wrote:
> Antoine Martin wrote:
>
> > It means that most of your code is not using threads at all, only the
> > bits that are *slow*
>
> Those are the only bits that use threads anyway.
>
> > I've lost track of your particular issue though, so maybe
On Wed, 2010-07-07 at 09:26 +0800, Jason Heeris wrote:
> Tim Evans wrote:
> > GTK+ 2.14.4
> > PyGObject 2.14.2
> > PyGTK 2.12.1
>
> Mine is
>
> GTK+ 2.20
> PyGObject 2.21.2
> PyGTK 2.17.1
>
> A few things about your changes confused me -
>
> 1. You call glib.idle_add, but never called glib.thre
On 2010-07-07 13:26, Jason Heeris wrote:
> Tim Evans wrote:
>> GTK+ 2.14.4
>> PyGObject 2.14.2
>> PyGTK 2.12.1
>
> Mine is
>
> GTK+ 2.20
> PyGObject 2.21.2
> PyGTK 2.17.1
>
> A few things about your changes confused me -
>
> 1. You call glib.idle_add, but never called glib.threads_init - won't
> th
Tim Evans wrote:
> GTK+ 2.14.4
> PyGObject 2.14.2
> PyGTK 2.12.1
Mine is
GTK+ 2.20
PyGObject 2.21.2
PyGTK 2.17.1
A few things about your changes confused me -
1. You call glib.idle_add, but never called glib.threads_init - won't
this break on Linux?
2. You use BOTH gtk.gdk.lock and glib.idle_ad
Antoine Martin wrote:
> It means that most of your code is not using threads at all, only the
> bits that are *slow*
Those are the only bits that use threads anyway.
> I've lost track of your particular issue though, so maybe this is not
> suitable for your use-case? How much slow work do you do
On 07/06/2010 03:53 PM, Jason Heeris wrote:
> Antoine Martin wrote:
>> I don't know of any examples unfortunately and I must admit that I spent
>> quite a bit of time getting to grips with it, but in the end it is
>> remarkably simple (much more simple than I first thought too - so don't
>> let tha
Antoine Martin wrote:
> I don't know of any examples unfortunately and I must admit that I spent
> quite a bit of time getting to grips with it, but in the end it is
> remarkably simple (much more simple than I first thought too - so don't
> let that put you off):
> import gtk.gdk
> gtk.gdk.threads
Tim Evans wrote:
> Something worth noting is that if you're targeting Windows then 2.a. is
> your *only* option.
In fact, gtk.gdk.threads_init() will freeze straight off, you don't
need to wait for threads to start.
> I would also point out that "whenever it next feels like it" is almost
> always
On 5 July 2010 17:53, Pietro Battiston wrote:
> Il giorno lun, 05/07/2010 alle 16.32 +0800, Jason Heeris ha scritto:
>> 3. I don't need to do the threads_enter/leave (or use the context
>> manager) if I only use glib.idle_add (or timeout_add, etc)
>
> No, you don't. If you don't really need thre
On 2010-07-05 20:32, Jason Heeris wrote:
>2. Any GTK interaction, such as emitting a signal from this new
> thread, must be either:
>a. done via glib.idle_add (if I'm happy to let GTK do it
> whenever it next feels like it), -OR-
>b. wrapped in gtk.gdk.threads_enter()/...leave()
On 5 July 2010 21:48, A.T.Hofkamp wrote:
> I was mostly triggered by the fact that you are doing asynchronous
> activities next to the GTK application, which are apparently complicated
> enough to use threads for.
It's not complicated, there's simply a time consuming operation involved.
> About
Jason Heeris wrote:
> On 5 July 2010 17:36, A.T.Hofkamp wrote:
>> Or you could drop threads entirely, and do your async activities using the
>> Twisted framework, designed for making asynchronous programs (where GTK
>> event handling is just one of the asynchronous sources).
>
> Please don't take
Il giorno lun, 05/07/2010 alle 18.55 +0800, Jason Heeris ha scritto:
> On 5 July 2010 18:32, Pietro Battiston wrote:
> > You wouldn't need threading if you could do:
>
> > def do_processing(self):
> >if self.counter < 1000:
> >import time
> >time.sleep(.01)
> >return T
On 07/05/2010 04:57 PM, Jason Heeris wrote:
> On 5 July 2010 17:36, A.T.Hofkamp wrote:
>> Or you could drop threads entirely, and do your async activities using the
>> Twisted framework, designed for making asynchronous programs (where GTK
>> event handling is just one of the asynchronous sources)
Il giorno lun, 05/07/2010 alle 18.09 +0800, Jason Heeris ha scritto:
> On 5 July 2010 17:53, Pietro Battiston wrote:
> > Apart from 2.c, I guess
> > http://faq.pygtk.org/index.py?file=faq20.006.htp&req=show
> > is clear enough?
>
> It's clear, except I can't tell if it applies to PyGObject 2.20 o
On 5 July 2010 18:05, Neil Benn wrote:
> I persevered however and threads work fine in Python - OK the GIL can make
> things a little more complicated but threading in Python is not much harder
> to use then in Java or C# (in fact because of the GIL and single processor I
> don't have to worry abo
Hello,
I agree with that wholeheartedly. I typical code in 3 or 4
languages and the other languages I use (C#, Java, etc) just have threads
which are easy to use. When I was told to use twisted I looked at the
website and though 'phew that is a lot to learn'. I was then about to drop
Py
Il giorno lun, 05/07/2010 alle 16.32 +0800, Jason Heeris ha scritto:
> Hi,
>
> I've been reading some conflicting advice on PyGTK and threading
> recently, probably because the API went through some fairly rapid
> changes recently.
>
> I'm a bit confused about the following points (consider them
On 5 July 2010 17:36, A.T.Hofkamp wrote:
> Or you could drop threads entirely, and do your async activities using the
> Twisted framework, designed for making asynchronous programs (where GTK
> event handling is just one of the asynchronous sources).
Please don't take this as a flame, but I've ha
Jason Heeris wrote:
> Hi,
>
> I've been reading some conflicting advice on PyGTK and threading
> recently, probably because the API went through some fairly rapid
> changes recently.
>
> I'm a bit confused about the following points (consider them in
> context of PyGTK/PyGObject unstable, ie. 2.1
Hi,
I've been reading some conflicting advice on PyGTK and threading
recently, probably because the API went through some fairly rapid
changes recently.
I'm a bit confused about the following points (consider them in
context of PyGTK/PyGObject unstable, ie. 2.17/2.21 respectively):
1. If I wan
21 matches
Mail list logo
