[PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization

[Hans-Christoph Steiner]

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 at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev