<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 23, 2020 at 11:22 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I have *never* seen watchdog bail in that case-- it just keeps<br>
spitting out "watchdog: signaling pd..." until I ctrl-c out of the<br>
terminal.<br></blockquote><div><br></div><div>Try Ctrl+M on Linux ALSA some time, and have the dialog just sit there. :)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Also, given various use cases with long-running number cruncher<br>
patches, watchdog *cannot* bail in any of those cases without solving<br>
the halting problem.<br></blockquote><div><br></div><div>It doesn't try to solve the halting problem. It's a very dumb little routine which just loops waiting for its socket to dry up. ;-)<br></div><div><br></div><div>I guess that the watchdog is just fine as long as the gui is still alive and kicking, no matter what the engine does.</div><div><br></div><div>About realtime priorities: Yes, there have been improvements in the API, but Pd doesn't use them AFAICT.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

So I'm just not sure what its purpose is.<br></blockquote><div><br></div><div>I guess that it's a left-over from the bad old days when we all had single core computers. At that time it was fairly easy to completely lock up the system with a runaway realtime process. Nowadays, this has become much harder, usually you can still kill that process.<br></div><div><br></div><div>Albert<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Jonathan<br>
<br>
On Fri, Oct 23, 2020 at 5:20 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
><br>
> On Fri, Oct 23, 2020 at 4:55 PM Albert Graef <<a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>> wrote:<br>
> ><br>
> > On Fri, Oct 23, 2020 at 10:03 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
> >><br>
> >> > I see that there are some fairly recent code changes in sys_domicrosleep() in vanilla, though. I'll port those and see whether that helps.<br>
> >><br>
> >> I don't think they will help.<br>
> ><br>
> ><br>
> > You're right, backporting those didn't help.<br>
> ><br>
> >> The problem is that if pd-watchdog<br>
> >> doesn't receive an acknowledgement it will shut down the backend.<br>
> ><br>
> ><br>
> > Yep, that's it. If I modify the watchdog so that it never bails out then both the message and the print dialog work alright. Of course that's not the proper solution ;-), but it proves that the watchdog is the culprit here. So we just have to find a way to keep it happy, see below.<br>
><br>
> I'm curious-- is there any extant user report of watchdog saving them<br>
> from having to hard reboot their machine (which is what I guess is<br>
> what it's there for)?<br>
><br>
> The thing is, this is the first case I've heard of where the GUI has<br>
> caused a hangup. And it's a false positive because the blocking call<br>
> was triggered by the user purposely and is temporary.<br>
><br>
> On the other hand, I've seen my backend lock down the CPU *all the<br>
> time*. Exponential explosion is the name of the game all through<br>
> g_editor.c, and there are various other freezes from external libs and<br>
> bugs. I have *never* seen watchdog bail in that case-- it just keeps<br>
> spitting out "watchdog: signaling pd..." until I ctrl-c out of the<br>
> terminal.<br>
><br>
> Also-- hasn't Linux realtime priority processing improved<br>
> significantly over the past decade to make it less likely to lock up<br>
> the machine? (I've only heard in general about improvements, so I'm<br>
> not sure about this.)<br>
><br>
> ><br>
> >> We can change the "message" dialog to something that doesn't block the<br>
> >> js engine. I'm not sure about the print dialog, though.<br>
> ><br>
> ><br>
> > Probably not much that we can do about the print dialog. And there might be other cases where things may go awry. Search index generation comes to mind -- we might just have been lucky there because this is a very quick operation on Linux, but it might give the same issue on slower computers.<br>
> ><br>
> > This really calls for a general solution where the gui informs the engine that it should keep the watchdog happy while it's executing a callback which may run for a while, and then inform it again when that callback is finished. That shouldn't be too hard to do, the engine already does this anyway when running gui-less. I'm working on it.<br>
><br>
> I'm curious what happens if we get rid of watchdog and run Purr Data<br>
> with realtime priorities on a current distro... :)<br>
><br>
> -Jonathan<br>
><br>
> ><br>
> > Albert<br>
> ><br>
> ><br>
> >><br>
> >> -Jonathan<br>
> >><br>
> >> ><br>
> >> > Albert<br>
> >> ><br>
> >> >><br>
> >> >> -Jonathan<br>
> >> >> _______________________________________________<br>
> >> >> L2Ork-dev mailing list<br>
> >> >> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> >> >> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > --<br>
> >> > Dr. Albert Gr"af<br>
> >> > Computer Music Research Group, JGU Mainz, Germany<br>
> >> > Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" rel="noreferrer" target="_blank">https://agraef.github.io/</a><br>
> >> > _______________________________________________<br>
> >> > L2Ork-dev mailing list<br>
> >> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> >> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
> >> _______________________________________________<br>
> >> L2Ork-dev mailing list<br>
> >> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> >> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Dr. Albert Gr"af<br>
> > Computer Music Research Group, JGU Mainz, Germany<br>
> > Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" rel="noreferrer" target="_blank">https://agraef.github.io/</a><br>
> > _______________________________________________<br>
> > L2Ork-dev mailing list<br>
> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div></div>