Cool! Many thanks for the clarification! Best wishes,
Ico Martin Peach <[email protected]> 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 > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
