<br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 11:30 AM, Thomas Grill <span dir="ltr"><<a href="mailto:gr@grrrr.org" target="_blank">gr@grrrr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Sorry, one more note:<div>In libpd, sched_tick is currently calling in the PROCESS macro in the context of the audio callback (in z_libpd.c).</div><div>The function sched_tick handles all timed objects (such as metro) and therefore triggers all kinds of message processing downstream, where also memory operations commonly happen.</div>
<div>In this sense, calling sys_domicrosleep at the end of PROCESS does not make the situation worse than it is right now.</div><div><br></div><div>gr~~~</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br></div></div></div></blockquote><div><br></div><div>Why doesn't sched_tick call sys_domicrosleep then?</div><div><br></div><div>That function is making sleep and lock calls that I don't think should be made in libpd's process loop verbatum - timing is handled by whatever audio callback mechanism is using libpd and locking is handled within the language / framework wrappers.</div>
<div><br></div><div>It looks like the meat and potatoes is the following funky guy:</div><div>
<p class="p1"><span class="s1">(*</span>sys_fdpoll<span class="s1">[i].</span>fdp_fn<span class="s1">)(</span>sys_fdpoll<span class="s1">[i].</span>fdp_ptr<span class="s1">, </span>sys_fdpoll<span class="s1">[i].</span>fdp_fd<span class="s1">);</span></p>
<p class="p1"><br></p><p class="p1">If this were to be utilized by libpd, we should probably create a new, barebones method that does this polling (whatever that is...).</p><p class="p1"><br></p><p class="p1">cheers,</p><p class="p1">
Rich</p></div></div>