[PD-dev] clock_delay question

[Ivica Ico Bukvic]

Cool! Many thanks for the clarification!

Best wishes,

Ico

Martin Peach <martin.peach at sympatico.ca> wrote:

>Ivica Ico Bukvic wrote:
>>>> Another question related to this. In the netclient.c (maxlib) there is
>>>> the following code excerpt:
>>>>
>>>> 	/* get's called when connection has been made */
>>>> static void netclient_tick(t_netclient *x)
>>>> {
>>>>     outlet_float(x->x_outconnect, 1);
>>>> 		/* add pollfunction for checking for input */
>>>> 	sys_addpollfn(x->x_fd, (t_fdpollfn)netclient_rcv, x);
>>>> }
>>>>
>>>> Isn't the outlet_float call here unsafe as it is being triggered by an
>>>> external potentially out-of-sync force (namely connection)? Shouldn't
>>>> this be done through clock_delay() just to be safe? If I understand this
>>>> correctly, Pd does audio in 64-byte chunks and then the data processing
>>>> in between. Is this correct?
>>>>
>>>> If so, how does Pd deal with such events if they happen during the times
>>>> the pd's message tree is not being traversed (e.g. during the dsp
>>>> cycle)?
>>> That is why they are poll functions. The poll functions are polled right 
>>> after the dsp update, in sys_microsleep(). A select call is made to see 
>>> if any of the file descriptors are ready for read/writing. So if the 
>>> socket connects at any random time, the float will only be sent out the 
>>> outlet after the dsp. Another poll function is then registered to check 
>>> for received data on the socket.
>>> sys_microsleep() is called from m_pollingscheduler(), Pd's main loop, in 
>>> m_sched.c, after the dacs are written, so (as I understand it), it is 
>>> safe to make calls from a pollfunction. I think it's only outlet writes 
>>> made directly from the dsp object's perform routine that are dangerous, 
>>> they should be scheduled for right after the dac writes using 
>>> clock_delay(0).
>>>
>>> Martin
>> 
>> Thanks for the explanation. I am not sure however how does this apply to
>> the aforesaid example, so I would greatly appreciate your insight in
>> that specific scenario. Namely:
>> 
>> In the netclient example is the outlet_float call ok even though the
>> netclient_tick function containing it is triggered by an external
>> out-of-sync force (namely network connection)? 
>
>Yes, because netclient_tick is called after a clock timeout that was 
>triggered by the connect routine running in a different thread.
>
>> If so, what ensures that
>> this particular call is not going to happen right in the middle of other
>> GUI stuff already being sent out and/or dsp loop as the network client
>> has no idea when that is actually happening? Shouldn't this be also
>> clock_delay()?
>> 
>
>It _is_ clock_delayed.
>netclient_tick() is associated with a clock in netclient_new() as:
>     x->x_clock = clock_new(x, (t_method)netclient_tick);
>and the x_clock is set to timeout in 0 milliseconds in 
>netclient_child_connect() after the socket connects, which can happen at 
>any time since it's running in a separate thread.
>The clock will only be checked at one point in the main loop, after the 
>dacs have been written, so the function it calls will run at a safe time.
>
>> In other words, are outlet_<something> calls safe to be made from
>> non-dsp functions no matter when they happen *or* are they safe to be
>> made only in objects that are being pushed by incoming data streams
>> (which is typically most of Pd objects, but not all, e.g. such as metro
>> for instance)? If latter is the case, I would say clock_delay(0) is
>> necessary even on the aforesaid call.
>> 
>
>I guess the rule is this:
>Outlet calls are safe as long as they are:
>1> outside of dsp perform routines and
>2> called from Pd's main thread.
>
>Martin
>