Re: Run a callback by GTask from an extension



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?

Regards,
Geza


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

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

Should I create a MainLoop object as it is shown in the example? I don't really get how that works?

Regards,
Geza

Hi 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:
Hi Philip,

Thanks for the quick response.

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.

Regards,
Geza

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]