[GSoC] Integrating LO with GNOME - WR#8

[Pranav Kant]

Hi,

After a bit of research and discussion with Miklos, I decided to go
with ThreadPool instead of using async queue approach, since I could
not find any downsides of using this approach. Though, this approach
seems to be working fine for the little testing that I have done, we
might want to switch to async queue approach because of a possible
optimization.

I don't know how much optimize this would make the process. Currently
we keep pushing the tasks (paintTile requests) on to the queue, and no
matter what, once its pushed to the queue, it will get processed
anyways. But sometimes, I think, the user does a lot of operations in
very short interval of time, and we might not need some pending
operations in the queue to get processed at all. For example, when the
user quickly zooms in and zooms out.

There doesn't seem to be any way to manipulate the queue that thread
pool internally has, hence making it impossible to do this "task
compression". We can switch to using async queue approach as mentioned
by Tomaz, if this optimization is worth it, otherwise we can just
stick to the existing implemented approach for the time being.

On Mon, Jul 20, 2015 at 6:05 PM, Pranav Kant <pranav913 at gmail.com> wrote:
> Hi Tomaz,
>
> On Mon, Jul 20, 2015 at 4:14 PM, Tomaž Vajngerl <quikee at gmail.com> wrote:
>> Hi,
>>
>> On Mon, Jul 20, 2015 at 7:02 PM, Pranav Kant <pranav913 at gmail.com> wrote:
>>>> I am making use of thread pool, but this pool consists of only single
>>>> thread. All the LOK calls will be queued and can reuse this thread,
>>>> hence saving me the time that it would take to create a new thread
>>>> (expensive process) for each LOK call.
>>>>
>>>> This was the reason behind making use of thread pool. I had no
>>>> intention of using more than one thread for LOK calls.
>>
>> You can create only one thread on start and put the processing of
>> async queue in a loop there:
>>
>> while (message = async_queue.pop())
>> {
>> ...process message...
>> }
>>
>> from other thread just push the messages that you want to process in
>> the other thread into the queue (btw. this is what is done in Android
>> implementation).
>>
>> The queue will block if you "pop" and there are no messages in th
>> queue - which means the thread will sleep until a new message arrives.
>>
>> Look at: https://developer.gnome.org/glib/stable/glib-Asynchronous-Queues.html
>
> Yeah, we can use this too.
>
>>
>> As you can see the thread pool uses it also - but using thread pool
>> with only one thread is kind of a hack to me, but it works too..
>>
>
> Yeah, it works. I saw it in some of the gnome modules also, for
> example, gnome-photos.
> I don't know, but it looks easier to me, to implement and to read. I
> will research more over this, and see what we can do.
>
>
> --
> Regards,
> Pranav Kant
> http://pranavk.me



-- 
Regards,
Pranav Kant
http://pranavk.me