Re: [PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization
On 2010-09-01 06:06, Hans-Christoph Steiner wrote: I refactored the startup/vwait code to be close to the pd-gui-rewrite/0.43 startup procedure, but I removed the timeout that I think was at the root of the problems here. I'll put together a patch once I test it a bit more. i wouldn't mind if you pushed it to your gitorious repo, si i can test as well. fgnasd IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization
On Wed, 2010-09-01 at 09:18 +0200, IOhannes m zmoelnig wrote:
On 2010-09-01 06:06, Hans-Christoph Steiner wrote:
I refactored the startup/vwait code to be close to the
pd-gui-rewrite/0.43 startup procedure, but I removed the timeout that I
think was at the root of the problems here. I'll put together a patch
once I test it a bit more.
i wouldn't mind if you pushed it to your gitorious repo, si i can test
as well.
fgnasd
IOhannes
My pd-extended.git is a bit of a mess right now, I'm still figuring out
how to manage pd-extended in git as cleanly as possible. I'll probably
nuke the pd-extended repository and start again. I'm thinking this is
the way to do it:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase
In the meantime, I attached this patch:
.hc
commit 90fdbc6ae7842f9603863667fe0f4b3d5ae303f4
Author: Hans-Christoph Steiner h...@eds.org
Date: Mon Aug 30 17:53:10 2010 -0400
reverted to pd-gui-rewrite startup minus the timeout
diff --git a/tcl/pd-gui.tcl b/tcl/pd-gui.tcl
index 65b42ee..f02c372 100755
--- a/tcl/pd-gui.tcl
+++ b/tcl/pd-gui.tcl
@@ -104,6 +104,9 @@ set TCL_BUGFIX_VERSION 0
# for testing which platform we are running on (aqua, win32, or x11)
set windowingsystem
+# variable for vwait so that 'pd-gui' will wait for 'pd' to show up
+set wait4pd init
+
# args about how much and where to log
set verbose $::pdwindow::maxverbosity
set stderr 0
@@ -466,14 +469,7 @@ proc pdtk_pd_startup {major minor bugfix test
set_base_font $sys_font $sys_fontweight
fit_font_into_metrics
pdsend pd init [enquote_path [pwd]] $oldtclversion $::font_measured_metrics
-::pd_bindings::class_bindings
-::pd_bindings::global_bindings
-::pd_menus::create_menubar
-::pdtk_canvas::create_popup
-::pdwindow::create_window
-::pd_menus::configure_for_pdwindow
-load_startup_plugins
-open_filestoopen
+set ::wait4pd started
}
# routine to ask user if OK and, if so, send a message on to Pd ##
@@ -656,6 +652,16 @@ proc main {argc argv} {
set ::fileopendir $::env(HOME)
}
}
+# wait for 'pd' to call pdtk_pd_startup with vital information
+vwait ::wait4pd
+::pd_bindings::class_bindings
+::pd_bindings::global_bindings
+::pd_menus::create_menubar
+::pdtk_canvas::create_popup
+::pdwindow::create_window
+::pd_menus::configure_for_pdwindow
+load_startup_plugins
+open_filestoopen
::pdwindow::verbose 1 -- done with main --
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization
I refactored the startup/vwait code to be close to the pd-gui-rewrite/0.43 startup procedure, but I removed the timeout that I think was at the root of the problems here. I'll put together a patch once I test it a bit more. .hc On Thu, 2010-07-15 at 08:39 -0700, Miller Puckette wrote: I think the wait4pd thing was serving a valid purpose but the way it worked had race conditions... OTOH, waiting for pd to timeout and doing something appropriate (like telling the user something then giving up) sounds like a good thing to do - but is it appropriate to have the gui just exit? Shouldn't it offer to kill the errant pd or something? cheers Miller On Thu, Jul 15, 2010 at 05:07:22PM +0200, IOhannes zm?lnig wrote: On 07/15/2010 04:46 PM, Hans-Christoph Steiner wrote: The vwait timeout would not be needed if we can rely on 'pd' to actually fully die when it exits/crashes. On Mac OS X at least it is often doesn't completely crash and the process just sits there doing who knows what. If this happens on startup, pd-gui's exec call will not return, and pdtk_pd_startup won't be called and pd-gui will just sit and wait forever, giving us a zombie pd-gui. The vwait stuff wouldn't be needed if we can rely of pd to exit completely on all platforms. Just removing the vwait stuff is just replacing one problem with another. sure. i'm only talking about the race-condition. whether the vwait is there for other things is entirely beyond my scope. iirc, this is the title of this thread as well. Relax, no one is suggesting fixing a race condition with a timeout. Can you describe how to reproduce the race condition? What's actually racing? Did Miller's changes fix it? i did not experience any problem with miller's changes so far (which does not mean that the race-condition is gone, it just didn't show up) racing was between pd-gui and pd: if the latter was to late, either pd-gui would timeout or the media menu would be initialized wrongly (no audio/midi APIs available) leaving all this aside, i still think that it is a good idea for Pd to be able to change the dynamic entries of the menu at any time. if the available APIs change, Pd could update the menu accordingly (sounds like a stupid idea? but if jackd is running, then the only really available API would be jack (OSS, ALSA, portaudio being all blocked by jackd; ich jackd stops, other APIs would become available again) gfmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization
On 07/15/2010 04:46 PM, Hans-Christoph Steiner wrote: The vwait timeout would not be needed if we can rely on 'pd' to actually fully die when it exits/crashes. On Mac OS X at least it is often doesn't completely crash and the process just sits there doing who knows what. If this happens on startup, pd-gui's exec call will not return, and pdtk_pd_startup won't be called and pd-gui will just sit and wait forever, giving us a zombie pd-gui. The vwait stuff wouldn't be needed if we can rely of pd to exit completely on all platforms. Just removing the vwait stuff is just replacing one problem with another. sure. i'm only talking about the race-condition. whether the vwait is there for other things is entirely beyond my scope. iirc, this is the title of this thread as well. Relax, no one is suggesting fixing a race condition with a timeout. Can you describe how to reproduce the race condition? What's actually racing? Did Miller's changes fix it? i did not experience any problem with miller's changes so far (which does not mean that the race-condition is gone, it just didn't show up) racing was between pd-gui and pd: if the latter was to late, either pd-gui would timeout or the media menu would be initialized wrongly (no audio/midi APIs available) leaving all this aside, i still think that it is a good idea for Pd to be able to change the dynamic entries of the menu at any time. if the available APIs change, Pd could update the menu accordingly (sounds like a stupid idea? but if jackd is running, then the only really available API would be jack (OSS, ALSA, portaudio being all blocked by jackd; ich jackd stops, other APIs would become available again) gfmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
