[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 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 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





----------------------------------------------------------------------------

'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