On Jul 15, 2010, at 10:08 AM, IOhannes m zmoelnig wrote:
On 2010-07-15 15:46, Hans-Christoph Steiner wrote:
That's the idea of the wait4pd stuff, to make sure that pd is started before continuing on. I don't think this is necessary. Do you have a way to trigger pd taking too long to start up?
yes: when using jack (with the new api), Pd will eventually start the jackd at startup, which can take some time (that's how i discovered the problem) or there is a network between Pd and Pd-gui. or my machine is slow.
imho, software that relies on "modern computers being fast enough to make the race-condition never happen" is simply bad.
i don't even like the wait4pd stuff, as it eventually will turn out. why do we have to make assumptions on how fast 2 asynchronous(!) processes happen? i think Pd should be able to handle such situations gracefully rather than eventually.
The options are wait forever or have a timeout. The vwait code provides a timeout. I am fine with having a long timeout for the conditions you describe but it would be harmful to not have a timeout because then you'll have a pd-gui process that is just sitting there waiting forever for pd to show up whether or not if ever will. As some point pd-gui should tell you that its not likely to happen and just quit.
For this reason, I think its a bad idea to get rid of the vwait code and move stuff to pdtk_pd_startup. If there are bugs with the vwait approach, I'd be happy to fix them. For what IOhannes describes here, it sounds like the timeout just needs to be increased. Perhaps there could be a -timeout flag to pd-gui to set it. Miller, did you actually see race conditions, or just pd-gui waiting forever?
.hc
----------------------------------------------------------------------------