Re: Blocking the UI from CPU-intensive gdbmi parsing

[Dodji Seketeli <dodji seketeli org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathon Jongsma a écrit :

>> Well, We have IDebugger::command_done_signal() that is emitted right
>> after
>> IDebugger sends the command GDB, if GDB acknowledges the command. So I
>> *think*
>> we could just start pulsing when we receive the
>> IDebugger::command_done_signal.
>> I think that would work, but would be hackish until GDB can really
>> notify us
>> about its progress.
> 
> So if I understand correctly, you're suggesting that we could handle
> this signal and start a timeout-based progress pulse.  then when we
> actually get the reply from gdb, we could disable the timeout and pulse
> progress as we parse the output (?)
>

Yeah, something along those lines. The idea is to start a progress pulse right
when get the IDebugger::command_done_signal, rather than waiting for the gdb
reply before starting the progress pulse.

>>> The other question I have about the above API is how to associate a
>>> certain progress event  with a particular operation.  Perhaps all
>>> debugger operations that can notify about progress can return a progress
>>> notifier object or something, e.g.:
>>>
>>> virtual ISomeNotifierSafePtr list_files (const UString &);
>>>
>>> And then if you want to be notified of progress you can connect to its
>>> signals.  I'm not sure how the internal implementation of this would
>>> work, but it seems like a reasonably clean API to me.  what do you
>>> think?
>>
>>
>> The way i see it is to have some possible long operations be invoked
>> through an
>> API that ressembles:
>>
>> void IDebugger::do_long_operation (sigc::slot<void, void>
>> &a_notification_slot);
>>
>> a_notification_slot would be the slot invoked to notify the progress.
>> For the
>> sake of simplicity, I choosed sigc::slot<void, void> in this exemple,
>> but it
>> could be a slot that has got a more useful signature, I guess.
> 
> hm, so that looks like basically the same sort of thing as my
> suggestion, except you're passing a slot as an argument to the debugger
> call, whereas in my prototype I'm passing a signal back from the
> debugger call.
> 
> So in my case, the user of the debugger API would look something like this:
> 
> IProgressNotifierSafePtr progress = debugger->list_files();
> progress->signal_progress_pulse ().connect (sigc::mem_fun(...));
> 
> and I've actually toyed around with the idea of adding some API to the
> progress notifier that would enable API users to cancel long-running
> commands, e.g.:  progress->cancel (); This could set a flag that the
> parser could check whenever it checks in to pulse the notifier and if it
> is set, it could abort the operation...  Obviously the idea is not
> fully-thought-out yet, but it could be useful.

Ah okay. I don't have any strong feeling against this, though I haven't thought
about it in detail.



> I will take a look at your branch.

Ah, cool, thanks :) It's still pretty much in the works. I'll post a little text
 here explaining what it's about shortly.

> Btw, I wasn't sure that I wanted to
> push my experimental notifier branch to git.gnome.org since I'm not sure
> it will be the approach we end up using.  So I pushed it to my homedir
> on gnome.org instead:
>  http://www.gnome.org/~jjongsma/git/nemiver.git/

Okay.

Seriously, I don't have any problem with you just pushing your branch in the
current nemiver repo on git.gnome.org. If it appears that you don't want the
branch anymore, you can just throw it away I guess. You have the commit access
to the repo, so you are a trusted person :)

> Do you know if git.gnome.org will provide a simpler way to host user
> repositories?

I have no idea about that, sorry.

> 
> If you have time, I'd love it if you could checkout my
> 'progress-notifier' branch and let me know what you think of the
> approach.   (If you want to see a demonstration of it in action, build
> that branch and select 'File > Open Source File ...' while debugging a
> non-trivial application).
> 

Sure, I'll give it a go when I have time. I hope during the week to come, and
I'll let you know.

Thanks for pushing this forward.

Cheers,

Dodji.

- --
Tant que l'on n'a pas la tête coupée, on peut espérer mettre un chapeau.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org

iEYEARECAAYFAknZFO4ACgkQPejI7lrem2F73wCfT97sWuF7ucZDpfsUuJSOk7qg
Ln0AnRBEZF9w60XFPN5JoIFl2MHu6dOh
=yhhQ
-----END PGP SIGNATURE-----