That's the idea of the wait4pd stuff, to make sure that pd is started before continuing on. I don't think this is necessary. Do you have a way to trigger pd taking too long to start up?
.hc
On Jul 15, 2010, at 2:57 AM, IOhannes m zmoelnig wrote:
if Pd takes too long to startup, Pd-gui will initialize the audio/ midi API-menus with NULL-lists; if Pd finally shows up, the menu cannot be modified anymore, and thus the user cannot select the API they want.
the fix moves the audio/midi APIs into a sub-menu of "Media", and provides a function ::pd_menus::build_media_api_menus that will clear the old API-menus and refill them with the new API-lists. this allows Pd-core, to update the API-lists after the GUI has been initialized.
tcl/pd-gui.tcl | 1 + tcl/pd_menus.tcl | 50 ++++++++++++++++++++++++++++++++ +----------------- 2 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/tcl/pd-gui.tcl b/tcl/pd-gui.tcl index c99decc..b4f20b3 100755 --- a/tcl/pd-gui.tcl +++ b/tcl/pd-gui.tcl @@ -460,6 +460,7 @@ proc pdtk_pd_startup {major minor bugfix test if {$::tcl_version >= 8.5} {find_default_font} set_base_font $sys_font $sys_fontweight fit_font_into_metrics
- ::pd_menus::build_media_api_menus $::pdwindow_menubar.media set ::wait4pd "started"
}
diff --git a/tcl/pd_menus.tcl b/tcl/pd_menus.tcl index fc617df..7157c5e 100644 --- a/tcl/pd_menus.tcl +++ b/tcl/pd_menus.tcl @@ -224,6 +224,32 @@ proc ::pd_menus::build_find_menu {mymenu} { -command {pdsend {pd finderror}} }
+## update the audio/midi API lists +# this is done by first clearing the menus, and then rebuilding them from scratch +proc ::pd_menus::build_media_api_menus {mymenu} {
- if { [winfo exists $mymenu.audio] } {
$mymenu.audio delete 0 [ $mymenu.audio index last]set audio_apilist_length [llength $::audio_apilist]for {set x 0} {$x<$audio_apilist_length} {incr x} {$mymenu.audio add radiobutton -label [lindex [lindex$::audio_apilist $x] 0] \
-command {menu_audio 0} -variable ::pd_whichapi \-value [lindex [lindex $::audio_apilist $x] 1]\-command {pdsend "pd audio-setapi $::pd_whichapi"}}- }
- if { [winfo exists $mymenu.midi] } {
$mymenu.midi delet 0 [ $mymenu.midi index last]set midi_apilist_length [llength $::midi_apilist]for {set x 0} {$x<$midi_apilist_length} {incr x} {$mymenu.midi add radiobutton -label [lindex [lindex$::midi_apilist $x] 0] \
-command {menu_midi 0} -variable ::pd_whichmidiapi \-value [lindex [lindex $::midi_apilist $x] 1]\-command {pdsend "pd midi-setapi $::pd_whichmidiapi"}}- }
+}
proc ::pd_menus::build_media_menu {mymenu} { variable accelerator $mymenu add radiobutton -label [_ "DSP On"] -accelerator "$accelerator+/" \ @@ -237,23 +263,13 @@ proc ::pd_menus::build_media_menu {mymenu} { $mymenu add command -label [_ "Load Meter"] \ -command {menu_doc_open doc/7.stuff/tools load-meter.pd}
- set audio_apilist_length [llength $::audio_apilist]
- if {$audio_apilist_length > 0} {$mymenu add separator}
- for {set x 0} {$x<$audio_apilist_length} {incr x} {
$mymenu add radiobutton -label [lindex [lindex$::audio_apilist $x] 0] \
-command {menu_audio 0} -variable ::pd_whichapi \-value [lindex [lindex $::audio_apilist $x] 1]\-command {pdsend "pd audio-setapi $::pd_whichapi"}- }
- set midi_apilist_length [llength $::midi_apilist]
- if {$midi_apilist_length > 0} {$mymenu add separator}
- for {set x 0} {$x<$midi_apilist_length} {incr x} {
$mymenu add radiobutton -label [lindex [lindex$::midi_apilist $x] 0] \
-command {menu_midi 0} -variable ::pd_whichmidiapi \-value [lindex [lindex $::midi_apilist $x] 1]\-command {pdsend "pd midi-setapi $::pd_whichmidiapi"}- }
- menu $mymenu.audio
- menu $mymenu.midi
- $mymenu add cascade -label [_ "Audio"] -menu $mymenu.audio
- $mymenu add cascade -label [_ "Midi"] -menu $mymenu.midi
- build_media_api_menus $mymenu
- if {$::windowingsystem ne "aqua"} { $mymenu add separator create_preferences_menu $mymenu.preferences
-- 1.7.1
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
On 2010-07-15 15:46, Hans-Christoph Steiner wrote:
That's the idea of the wait4pd stuff, to make sure that pd is started before continuing on. I don't think this is necessary. Do you have a way to trigger pd taking too long to start up?
yes: when using jack (with the new api), Pd will eventually start the jackd at startup, which can take some time (that's how i discovered the problem) or there is a network between Pd and Pd-gui. or my machine is slow.
imho, software that relies on "modern computers being fast enough to make the race-condition never happen" is simply bad.
i don't even like the wait4pd stuff, as it eventually will turn out. why do we have to make assumptions on how fast 2 asynchronous(!) processes happen? i think Pd should be able to handle such situations gracefully rather than eventually.
fgmasdr IOhannes
On Jul 15, 2010, at 10:08 AM, IOhannes m zmoelnig wrote:
On 2010-07-15 15:46, Hans-Christoph Steiner wrote:
That's the idea of the wait4pd stuff, to make sure that pd is started before continuing on. I don't think this is necessary. Do you have a way to trigger pd taking too long to start up?
yes: when using jack (with the new api), Pd will eventually start the jackd at startup, which can take some time (that's how i discovered the problem) or there is a network between Pd and Pd-gui. or my machine is slow.
imho, software that relies on "modern computers being fast enough to make the race-condition never happen" is simply bad.
i don't even like the wait4pd stuff, as it eventually will turn out. why do we have to make assumptions on how fast 2 asynchronous(!) processes happen? i think Pd should be able to handle such situations gracefully rather than eventually.
The options are wait forever or have a timeout. The vwait code provides a timeout. I am fine with having a long timeout for the conditions you describe but it would be harmful to not have a timeout because then you'll have a pd-gui process that is just sitting there waiting forever for pd to show up whether or not if ever will. As some point pd-gui should tell you that its not likely to happen and just quit.
For this reason, I think its a bad idea to get rid of the vwait code and move stuff to pdtk_pd_startup. If there are bugs with the vwait approach, I'd be happy to fix them. For what IOhannes describes here, it sounds like the timeout just needs to be increased. Perhaps there could be a -timeout flag to pd-gui to set it. Miller, did you actually see race conditions, or just pd-gui waiting forever?
.hc
----------------------------------------------------------------------------
On 07/15/2010 04:21 PM, Hans-Christoph Steiner wrote:
The options are wait forever or have a timeout. The vwait code provides a timeout. I am fine with having a long timeout for the conditions you describe but it would be harmful to not have a timeout because then you'll have a pd-gui process that is just sitting there waiting forever for pd to show up whether or not if ever will. As some point pd-gui should tell you that its not likely to happen and just quit.
my approrach was not to wait at all, and as soon as pd shows up dynamically incorporate the info. no timeout, no waiting, no deadlock no racecondition.
For this reason, I think its a bad idea to get rid of the vwait code and move stuff to pdtk_pd_startup. If there are bugs with the vwait approach, I'd be happy to fix them. For what IOhannes describes here, it sounds like the timeout just needs to be increased. Perhaps there
i experienced a race-condition! please do not fix race-conditions by increasing a timeout.
fgmar IOhannes
On Jul 15, 2010, at 10:28 AM, IOhannes zmölnig wrote:
On 07/15/2010 04:21 PM, Hans-Christoph Steiner wrote:
The options are wait forever or have a timeout. The vwait code provides a timeout. I am fine with having a long timeout for the conditions you describe but it would be harmful to not have a timeout because then you'll have a pd-gui process that is just sitting there waiting forever for pd to show up whether or not if ever will. As some point pd-gui should tell you that its not likely to happen and just quit.
my approrach was not to wait at all, and as soon as pd shows up dynamically incorporate the info. no timeout, no waiting, no deadlock no racecondition.
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.
For this reason, I think its a bad idea to get rid of the vwait code and move stuff to pdtk_pd_startup. If there are bugs with the vwait approach, I'd be happy to fix them. For what IOhannes describes here, it sounds like the timeout just needs to be increased. Perhaps there
i experienced a race-condition! please do not fix race-conditions by increasing a timeout.
fgmar IOhannes
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?
.hc
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
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
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
I thought about killing the errant pd quite a bit but I couldn't figure out how to detect when to kill it. Then I also realized that really the problem is likely in Pd's code, I think it was something in s_inter.c or somewhere that was trying to deal with the console that Wish sets up. I think the best solution would be to fix why 'pd' doesn't always fully quit, then I think since 'pd-gui' is calling 'pd' in an exec, it would die whenever 'pd' dies. I'll see if I can find some details...
.hc
On Jul 15, 2010, at 11:39 AM, 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
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
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
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
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-r...
In the meantime, I attached this patch:
.hc
On Jul 15, 2010, at 11:07 AM, 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.
So you were seeing something like Tcl/pd-gui pegging the CPU when getting stuck in a loop? Or was it that pd-gui was sitting there waiting doing nothing?
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)
Ok, so you made this happen by having pd start jackd? I am trying to figure out how to reproduce it so I can tell what's happening.
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)
That sounds good to me too, though I don't think that having jackd running should hide the other Audio options. Just because jackd is running doesn't mean that the user might want to switch to ALSA. Or am I missing some annoying technical detail?
.hc
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
On 07/15/2010 05:59 PM, Hans-Christoph Steiner wrote:
On Jul 15, 2010, at 11:07 AM, 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.
So you were seeing something like Tcl/pd-gui pegging the CPU when getting stuck in a loop? Or was it that pd-gui was sitting there waiting doing nothing?
no, pd-gui was there, pd was there, but i had not a single entry in the audio/midi API list. i couldn't select the backend. i heard nothing.
pd was working fine.
fgmasrd IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Miller Puckette