[PD-dev] clock_delay question

[Martin Peach]

Ivica Ico Bukvic wrote:
>> Likewise, I noticed that netclient (maxlib) uses something called
>> sys_pollfn() call, is this safe?
> 
> Oops, I meant sys_addpollfn()...
> 
> 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