Preemption in python

[Kurtis Heimerl]

I ran a brief program to just test the threading properties of my VM, it
seems to be preempting that application.

Are there any interesting locks in the gtk package that I might not be
playing well with?

The reader thread that only runs on a blocking call is at the end of my
response.

I'll explain a bit more. This thread is spawned, I also have the main thread
running a gtk windowed gui. The gui has it's own threads to deal with button
presses and such. The problem is that the gui never seems to let anyone else
run. Only on button presses that cause blocking calls (
ossaudiodev.audio.read for instance) does the reader thread print anything.

Likewise, this thread blocks the GUI thread. There's really just no
preemption at all going on, and it's exceedingly strange.

The GIL locking could be part of my problem. I'm not explicitly releasing
any locks, I have not used the lock interface at all. That shouldn't cause
the behavior I'm seeing though right?

class ReaderThread( threading.Thread ):

    def __init__(self, dtn):
        self.dtn = dtn
        threading.Thread.__init__(self)

    def run(self):
        print("RUNNING")
        while(True):
            bundle = api.recv(self.dtn.handle, DTN_PAYLOAD_MEM, 10)
            if(bundle):
                print("RECEIVED BUNDLE")
            else:
                print("NO BUNDLE")

Thanks for the help, I really appreciate it. I'm totally blocked on this
without you folk's help.

On 9/23/07, Evan Klitzke <evan at yelp.com> wrote:
>
> On Sat, 2007-09-22 at 19:28 -0700, Kurtis Heimerl wrote:
> > Hi, I'm developing my first python application, a multi-threaded cell
> > phone gadget on ubuntu 7.10. I've just split off my first thread, and
> > I've noticed something extremely strange: There doesn't seem to be any
> > preemption. There are currently two threads, one that pings a storage
> > service to see if there are messages available, and the other that
> > runs the gtk windows. If I do not explicitly yield either one, it runs
> > forever. I'm assuming this is a setting somewhere, but that's a very
> > strange default behavior.
> >
> > How do I get this to go about preempting these threads? Any advice
> > would be helpful. Thanks!
>
> I'm far from an expert in threaded Python applications, but threading
> ought to work out of the box. By default the Python interpreter will
> switch threads every 100 bytecode instructions
> (http://docs.python.org/api/threads.html).
>
> Note that if you are synchronizing around a lock, you may need to sleep
> before trying to reacquire the the lock to completely exit the critical
> section. A good overview of this (and the Python threading model) can be
> found at http://linuxgazette.net/107/pai.html
>
> --
> Evan Klitzke <evan at yelp.com>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20070923/b1604b6e/attachment.html>