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