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