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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
