Cool! Many thanks for the clarification!
Best wishes,
Ico
Martin Peach <martin.peach(a)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
>