By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,548 Members | 1,487 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,548 IT Pros & Developers. It's quick & easy.

threading troubles

P: n/a
Hi folks

What am I doing wrong in the following? I just want to run fluidsynth in
the background.
#########################################
class MyThread(threading.Thread):
def __init__(self, cmd, callback):
self.__cmd = cmd
self.__callback = callback
threading.Thread.__init__(self)

def run(self):
os.system(self.__cmd)
self.__callback('abcd')
return
cmd=midiplay+' '+fmidi
xc=MyThread(cmd,addlog)
xc.start()
######################
midiplay is 'fluidsynth -ni /home/mysndfont.sf2 mymidi.mid'
addlog is a function which prints the log.

If I run it only with xc.start() it does not run the program as in
os.system. However if I put
xc.start()
xc.run()

then it starts and runs it in foreground with my pygtk ui non responsive.

What am I missing!

Thanks for any ideas
sree
Jul 10 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
you don't need twisted to run processes in the background, either.
os.popen* returns a file or set of files representing std streams
immediately
subprocess.Popen is a spiffy little object new in 2.4 and available for
download for 2.3. check the module docstrings for usage tips.

you can use threads, but try doing it the python way instead of the
java way. ;-)
def func(cmd, callback):
os.system(cmd)
callback()
xc = threading.Thread(target=func, args=(cmd, callback))
xc.start()
sreekant wrote:
Hi folks

What am I doing wrong in the following? I just want to run fluidsynth in
the background.
#########################################
class MyThread(threading.Thread):
def __init__(self, cmd, callback):
self.__cmd = cmd
self.__callback = callback
threading.Thread.__init__(self)

def run(self):
os.system(self.__cmd)
self.__callback('abcd')
return
cmd=midiplay+' '+fmidi
xc=MyThread(cmd,addlog)
xc.start()
######################
midiplay is 'fluidsynth -ni /home/mysndfont.sf2 mymidi.mid'
addlog is a function which prints the log.

If I run it only with xc.start() it does not run the program as in
os.system. However if I put
xc.start()
xc.run()

then it starts and runs it in foreground with my pygtk ui non responsive.

What am I missing!

Thanks for any ideas
sree
Jul 10 '06 #2

P: n/a
Hi there

I tried as advised. Now the function gets called only after I hit quit
button which calls gtk.main_quit() at which point, the ui stays on but
not responsive, while the fluidsynth runs in the fg, then ui disappears
as the fluidsynth finishes and presumably the thread dies.
xc = threading.Thread(target=player,args=(midicmd,fmidi ,addlog))
xc.start()

def player(mp,fm,callback):
res=os.system(mp+' '+fm)
os.remove(fm)
return

I tried in the player, both os.popen3 and os.system and os.popen3 with
cmd+' &' and the same with os.system . But all do the same thing.

Any ideas!
Ta
sree
>
you can use threads, but try doing it the python way instead of the
java way. ;-)
def func(cmd, callback):
os.system(cmd)
callback()
xc = threading.Thread(target=func, args=(cmd, callback))
xc.start()

Jul 10 '06 #3

P: n/a
sreekant wrote:
Hi folks

What am I doing wrong in the following? I just want to run fluidsynth in
the background.
Others have pointed you at os.popen. In non-crippled languages, use
processes (e.g. popen) when you wish to preserve the years of hard work
that OS designers put into protected memory. Use threads only when you
know why you want to abandon such and share all memory. 95% or more
of the time when you're making the multiprocessing decision, threads
are the wrong choice. 5% (or less) of the time they're indispensable.
But if you're just looking for asychronous processing and don't know
why you need to abandon memory protection, go with processes.

Jul 11 '06 #4

P: n/a
>>>>sreekant <sk*****@lithium.com(S) wrote:
>SHi folks
SWhat am I doing wrong in the following? I just want to run fluidsynth in
Sthe background.
S#########################################
Sclass MyThread(threading.Thread):
S def __init__(self, cmd, callback):
S self.__cmd = cmd
S self.__callback = callback
S threading.Thread.__init__(self)
>S def run(self):
S os.system(self.__cmd)
S self.__callback('abcd')
S return
>Scmd=midiplay+' '+fmidi
Sxc=MyThread(cmd,addlog)
Sxc.start()
>S######################
Smidiplay is 'fluidsynth -ni /home/mysndfont.sf2 mymidi.mid'
Saddlog is a function which prints the log.
>SIf I run it only with xc.start() it does not run the program as in
Sos.system. However if I put
Sxc.start()
Sxc.run()
>Sthen it starts and runs it in foreground with my pygtk ui non responsive.
You shouldn't call run() yourself. It is for the thread library itself.
I tried your example with cmd='ls -l' and it works. If I put a print
'started' after the xc.start(), it prints that before the output of ls -l,
indicating that ls -l is running in the background. (Of course the actual
order is up to the scheduler.) Maybe running it inside a pygtk program
could be different but I wouldn't know why.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org
Jul 11 '06 #5

P: n/a
I decided in the end to use fork and all is well.

Thanks
sree
Jul 11 '06 #6

P: n/a
>>>>sreekant <sk*****@lithium.com(S) wrote:
>SI decided in the end to use fork and all is well.
But how are you doing the callback then? From your code it looks like the
callback is called after the external command finishes. The callback would
then be called in the child process, not in the parent process, I think. Or
do you have a solution for that?
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org
Jul 11 '06 #7

P: n/a
Piet van Oostrum wrote:
>>>>>sreekant <sk*****@lithium.com(S) wrote:
>SI decided in the end to use fork and all is well.

But how are you doing the callback then? From your code it looks like the
callback is called after the external command finishes. The callback would
then be called in the child process, not in the parent process, I think. Or
do you have a solution for that?
I am not calling the callback now.

It is a pygtk interface to octavia music description language I wrote. I
have a button "Play" which reads the text in the gtk.TextView , converts
it to midi and calls fluidsynth with the resulting midi file.

I want the ui to be accessible during the midi play because, the midi
play can some times be a long piece of music.

I also have a log window which is another textview. I was loading the
result of

res=os.popen3(my_command)
report=res[1].read()+'\n'+res[2].read()
logwindow gets the report added to it.

However now I just put a message saying "playing midi"

I don't know any way out at the moment.

################

What I need is when I click on the play button, the fileplay(widget)
function that gets called should be able to start a new thread or a fork
which executes the commands and updates the ui.logwindow which is a
textview with the output of os.popen3.

During the execution the ui should be usable.

Please see the scala program in this package
http://sourceforge.net/projects/octavia . Checkout fileplay() function
in the most latest version 0.22 .

I don't want to attach the whole program to this message and annoy everyone.

Below is the function causing probs.

Ta
sree

###############################
def fileplay(x):
global conf,bdir,bgplay
lbuf.delete(lbuf.get_start_iter(),lbuf.get_end_ite r())
dat=buf.get_text(buf.get_start_iter(),buf.get_end_ iter())
if not len(dat)>0:
return

#see if the temporary dir to save temp gmc and midi exists
#if not create it
tempf=bdir+os.sep+'temp'+os.sep
try:
if not os.path.exists(tempf):
os.mkdir(tempf)
except:
addlog(traceback.format_exc())
return
#save octavia in to a count+1 text file
if os.path.exists(tempf):
try:
fbase=tempf+getcnt()
fmidi=fbase+'.midi'
f=open(fbase,'w')
f.write(dat)
f.close()
except:
addlog(traceback.format_exc())
#run octavia
addlog("Compiling to midi")
if conf.has_key('octavia'):
text2midi=conf['octavia']
else:
addlog("Config doesn't exist. Trying default octavia")
text2midi='octavia'
try:
res=os.popen3(text2midi+' '+fbase+' '+fmidi)
addlog(res[1].read()+res[2].read())
except:
addlog(traceback.format_exc())
return
# if midi exists, we succeded. play midi
if os.path.exists(fmidi):
addlog("Trying to play midi")
if conf.has_key('midiplayer'):
midiplay=conf['midiplayer']
else:
addlog("Config doesn't exist. Trying default timidity")
midiplay='timidity'

# start playing in a fork
pid=os.fork()
if pid:
pass
else:
os.popen3(midiplay+' '+fmidi)
sys.exit(0)
Jul 11 '06 #8

P: n/a
On 2006-07-10, sreekant <sk*****@lithium.comwrote:
Hi folks

What am I doing wrong in the following? I just want to run fluidsynth in
the background.
#########################################
class MyThread(threading.Thread):
def __init__(self, cmd, callback):
self.__cmd = cmd
self.__callback = callback
threading.Thread.__init__(self)

def run(self):
os.system(self.__cmd)
self.__callback('abcd')
return
cmd=midiplay+' '+fmidi
xc=MyThread(cmd,addlog)
xc.start()
######################
midiplay is 'fluidsynth -ni /home/mysndfont.sf2 mymidi.mid'
addlog is a function which prints the log.

If I run it only with xc.start() it does not run the program as in
os.system. However if I put
xc.start()
xc.run()

then it starts and runs it in foreground with my pygtk ui non responsive.

What am I missing!
You may be missing nothing. If I recall correctly a similar problem was
once reported on the pygtk-list. Some investigation showed that some
programs couldn't be reliably run from a thread, using os.system.

--
Antoon Pardon
Jul 12 '06 #9

P: n/a
Oh dear. For the time being I will leave it with fork and leave it at that.

Ta
sree
You may be missing nothing. If I recall correctly a similar problem was
once reported on the pygtk-list. Some investigation showed that some
programs couldn't be reliably run from a thread, using os.system.
Jul 12 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.