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

[Albert Graef]

On Fri, Oct 23, 2020 at 11:22 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> > 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.
>

Try Ctrl+M on Linux ALSA some time, and have the dialog just sit there. :)

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

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. ;-)

I guess that the watchdog is just fine as long as the gui is still alive
and kicking, no matter what the engine does.

About realtime priorities: Yes, there have been improvements in the API,
but Pd doesn't use them AFAICT.

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

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.

Albert


> -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
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201023/0016bccc/attachment-0001.html>