[L2Ork-dev] Purr Data: File / Print... PDF

[Jonathan Wilkes]

> I have *never* seen watchdog bail in that case-- it just keeps
spitting out "watchdog: signaling pd..." until I ctrl-c out of the
terminal.

Also, given various use cases with long-running number cruncher
patches, watchdog *cannot* bail in any of those cases without solving
the halting problem.

So I'm just not sure what its purpose is.

-Jonathan

On Fri, Oct 23, 2020 at 5:20 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>
> On Fri, Oct 23, 2020 at 4:55 PM Albert Graef <aggraef at gmail.com> wrote:
> >
> > On Fri, Oct 23, 2020 at 10:03 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> >>
> >> > 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.
> >>
> >> I don't think they will help.
> >
> >
> > You're right, backporting those didn't help.
> >
> >> The problem is that if pd-watchdog
> >> doesn't receive an acknowledgement it will shut down the backend.
> >
> >
> > 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.
>
> I'm curious-- is there any extant user report of watchdog saving them
> from having to hard reboot their machine (which is what I guess is
> what it's there for)?
>
> The thing is, this is the first case I've heard of where the GUI has
> caused a hangup. And it's a false positive because the blocking call
> was triggered by the user purposely and is temporary.
>
> On the other hand, I've seen my backend lock down the CPU *all the
> time*. Exponential explosion is the name of the game all through
> g_editor.c, and there are various other freezes from external libs and
> bugs. I have *never* seen watchdog bail in that case-- it just keeps
> spitting out "watchdog: signaling pd..." until I ctrl-c out of the
> terminal.
>
> Also-- hasn't Linux realtime priority processing improved
> significantly over the past decade to make it less likely to lock up
> the machine? (I've only heard in general about improvements, so I'm
> not sure about this.)
>
> >
> >> We can change the "message" dialog to something that doesn't block the
> >> js engine. I'm not sure about the print dialog, though.
> >
> >
> > 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.
> >
> > 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.
>
> I'm curious what happens if we get rid of watchdog and run Purr Data
> with realtime priorities on a current distro... :)
>
> -Jonathan
>
> >
> > Albert
> >
> >
> >>
> >> -Jonathan
> >>
> >> >
> >> > Albert
> >> >
> >> >>
> >> >> -Jonathan
> >> >> _______________________________________________
> >> >> L2Ork-dev mailing list
> >> >> L2Ork-dev at disis.music.vt.edu
> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >> >
> >> >
> >> >
> >> > --
> >> > Dr. Albert Gr"af
> >> > Computer Music Research Group, JGU Mainz, Germany
> >> > Email: aggraef at gmail.com, web: https://agraef.github.io/
> >> > _______________________________________________
> >> > L2Ork-dev mailing list
> >> > L2Ork-dev at disis.music.vt.edu
> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
> >> _______________________________________________
> >> L2Ork-dev mailing list
> >> L2Ork-dev at disis.music.vt.edu
> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >
> >
> >
> > --
> > Dr. Albert Gr"af
> > Computer Music Research Group, JGU Mainz, Germany
> > Email: aggraef at gmail.com, web: https://agraef.github.io/
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev