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

[Hans-Christoph Steiner]

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