GezaRegards,Hi Philip,I did some debugging yesterday and it looks like asynchronous file read and GLib.add_timeout() works perfectly. But now the slow part seems to be in the then closure of Promises like https://github.com/elvetemedve/gnome-shell-extension-system-monitor/blob/master/System_Monitor%40bghome.gmail.com/meter.js#L237-L245 In this case I don't see an async version of the glibtop_get_proc_mem() method in the documentation. So it looks like I need to iterate the mainloop somehow while the calculation is in progress. Could you give me a hint how to do that?
<philip chimento gmail com> ezt írta (időpont: 2017. ápr. 28., P, 7:00):On Thu, Apr 27, 2017 at 2:23 PM Géza Búza <bghome gmail com> wrote:Hi Philip,Thanks for the example.
I have similar code to load file contents, see the read() method here: https://github.com/elvetemedve/gnome-shell-extension-system-monitor/blob/master/System_Monitor%40bghome.gmail.com/helpers/file.js#L16-L31
I don't see the issue with it. The synchronous version is still there, but not used any more: https://github.com/elvetemedve/gnome-shell-extension-system-monitor/blob/master/System_Monitor%40bghome.gmail.com/file.jsI have read that the recently released Gnome started to support Promises, but so far I used a polifill https://github.com/elvetemedve/gnome-shell-extension-system-monitor/blob/master/System_Monitor%40bghome.gmail.com/helpers/promise.jsShould I create a MainLoop object as it is shown in the example? I don't really get how that works?
Regards,
GezaHi Géza,It looks reasonably correct, indeed. Could it be that you are accidentally importing the synchronous file.js somewhere in your code?You will indeed need a main loop to be running, in order for the GLib.timeout_add in your polyfill to work. But, I'm pretty sure gnome-shell should already be running one for you. Maybe someone else on this list can explain whether that's the case.Regards,Philip C<philip chimento gmail com> ezt írta (időpont: 2017. ápr. 27., Cs, 17:20):On Thu, Apr 27, 2017, 05:03 Géza Búza <bghome gmail com> wrote:GezaRegards,So it's single threaded, what a pity. The long running operation is IO and I already refactored my code to use async functions of GIO. I used Promise objects to handle the IO operations from _javascript_. The problem is that I need to wait for all IO calls to be completed before I can process the output and I done it with Promise.all() which waits for all Promises to be fulfilled. But that makes the code synchronous again. I could chain the IO calls, but that would require more refactoring.Hi Philip,Thanks for the quick response.Hi Geza,Promise.all should not make the code synchronous. I wonder if you are maybe using the synchronous Gio APIs inside your Promise wrapping code.Check wrapPromise() in the top half of [1] for an example.Regards,Philip C<philip chimento gmail com> ezt írta (időpont: 2017. ápr. 27., Cs, 2:41):On Wed, Apr 26, 2017, 15:08 Géza Búza <bghome gmail com> wrote:Hi everybody,
I run into an issue while developing an extension for Gnome Shell.
Long running _javascript_ code can make the whole Gnome Shell unresponsive for a second. Since I cannot reduce the execution time of the long running code, I want to move it out of the main loop's thread to a new one to make the UI update independent. I found that the best way would be to create a GTask to run my synchronous JS code asynchronously.Hi Geza,GJS is single-threaded; you can't run JS code from a separate thread. GTask, as you have noticed, is not usable from GJS and this is one of the reasons why.However, if your long-running operation is I/O, then you can simply use Gio's asynchronous operations and not worry about blocking the UI. Effectively Gio will decide whether to run the C code in a thread or not.If it is a long-running calculation or something like that, then you will have to iterate the main loop yourself often enough during the calculation so that the UI doesn't block.Regards,Philip C--Üdvözlettel,Búza Géza--Üdvözlettel,Búza Géza--Üdvözlettel,Búza Géza