Re: Rhythmbox Predictive Playback - Weekly Report

["Charlotte Curtis" <c f curtis gmail com>]

Wow, I get back from a long weekend and there's all kinds of
responses.  Awesome!

>> Last week was a learning experience for me: convincing Python to
>> launch executables without causing the entire Rhythmbox GUI to lock
>> up.
>
> Hm. Do you know what the problems caused? Is it that Python blocked until the execution of the called programm finished?
> How did you try it?
>
I tried it by activating my plugin and trying to use the GUI while it
was running, and it just wouldn't respond, even though nothing was
really using the CPU.  As soon as it's in the middle of executing
something in the plugin (even if it's time.idle()) the program is
unresponsive.

>> I tried a number of things - threads caused problems because I
>> was launching the program from a loop and I ended up with hundreds of
>> little spawned processes, whereas I only wanted one to go at a time.
>>
> yeah, threading sucks :P But still, couldn't you use kind of a counter to check whether you've already called the program? (Yeah, thread safety... I know)

I've been playing around with this a little (using a switch to tell
when the process has finished or not), it might be the way to go.

> If you didn't try the subprocess module[1] already, give it a try!

Thanks Toby, I have been using the subprocess module, which spawns a
process just fine.  However, the problem is I need to detect when the
process has finished.  Let's say I do proc = subprocess.Popen([args])
- if I then do proc.wait(), Rhythmbox hangs (or os.wait(),
os.waitpid(), etc).  So, my challenge is to find a way to wait for the
process to finish without actually getting stuck in a "waiting" loop.
If I could get the process to emit a signal when it's completed,
that'd be awesome. Otherwise, I'm probably going to have to go back
and look at threading.

On Mon, Jun 30, 2008 at 11:42 PM, Arun Tejasvi Chaganty
<arunchaganty gmail com> wrote:
> I'm not entirely sure if what I'm saying will help, but I thought I'd
> share my views on this. From what I've read in the glib docs[1], you can
> associate a GMainLoop with a GMainContext. The mainloop basically keeps
> track of a number of event sources. The "main" loop, i.e. the one run by
> Rhythmbox, would be running with the default context. Perhaps you could
> set yours with a custom context, that way it won't interfere with
> Rhythmbox's.
>
I hadn't heard about that, thanks!  It'd be great if I could use the
glib stuff, because it does exactly what I need - if only I were
working on a standalone program instead of a plugin, then I wouldn't
need to worry about mainloops-in-mainloops.

Thanks for the help guys,

Charlotte