[PD-dev] clock_delay question

[Martin Peach]

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