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

[Jonathan Wilkes]

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