[PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization
Hans-Christoph Steiner
hans at at.or.at
Thu Jul 15 17:55:49 CEST 2010
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
More information about the Pd-dev
mailing list