Attention massive speed up of the debugger

[dmoore]

No, I do not have any documentation about that (except for the wxwidgets docu).

It's just a question.

If it is sure, that we cannot get one of the events while we are processing one of them, there is no problem using this (splitting the messages in debuggergdb's ParseOutput and call the drivers ParseOutput for each line).

It can happen if someone does wxMesssageBox() or shows another modal dialog.
I've tested it with two timers. I don't know if there aren't any other cases where you can send/receive events from the queue inside a handler of another event?

Based on some previous experience with this, I would think that so long as the handler does not invoke blocking operations that pump the message queue (e.g. modal dialogs) you should be ok. Think about the implications if this wasn't true: how could you do any reliable event handling if new events could interrupt and change the state of the app?

I don't think an output line can be split in the middle, and if it can, this might happen in your code and in the original code.

Couldn't a really really long string be split between buffers? I guess this can only happen if you happen to read the output quicker than it is being written by GDB (not impossible, right?). You could reduce the risk of this happening by continuing to read until IsInputAvailable() returns false (though even this may be error prone):

Code

    while(process->IsInputAvailable())
    {
        stdin_stream->Read(buffer,maxchars);
        //append buffer to wxstring or whatever
    }

[cbexaminr]

(oops, post was started in other thread, which hosts this quote:)

Haha, this is another problem an has nothing to do with filling the Disassembly window - http://forums.codeblocks.org/index.php/topic,11298.0.html

Unclear to me from this thread - is some form of this change/patch in current source (trunk? wxpropgrid_debugger branch?) at the moment or not?  (The actual patch doesn't seem to exist at the linked paths on smrt-is-a-geek anymore, so was unable to quickly check for myself.)

(Don't know if Jens reverted entire patch, or just some particular problematic part of it.  And then if that trunk revision was part of debugger branch, or not.)

If the problem it "creates" can already occur (as obfus indicated in one post there), I don't see why it wouldn't be (unless it made it much more likely to occur, as possibly happened for Jens)..

somewhat OT (related to other thread and operator+ vs .insert change in splitting debugger in two thread):
this is also, at least the suggestion using wxArrayStrings, a place where unnecessary allocations/processing would be done.  (Jens mentioned that possibility, as a possible no-win change.)  It appears (based on my reading of that thread) for (all) ParseOutput()s to remain happy, something somewhere has to do the newline parsing, it could be done around those parseoutput calls, without any add'l allocation(s) - the sticky point is handling the partial lines that may occur across buffer boundaries, although that should be possible as well.  The other sticky point would be output which will not be terminated by the '\n's, I believe you mentioned some 'set prompt' item as such a case. 

How does that 'set prompt' instance function now?

Is remote debugging (across _slow_ network) more susceptible in any way, to this possibility (split output received), or does something (gdb/server?) try to make sure an output "bundle" is sent/received atomically, at least for MI interface?

[oBFusCATed]

I understood almost nothing from your post...

Is remote debugging (across _slow_ network) more susceptible in any way, to this possibility (split output received), or does something (gdb/server?) try to make sure an output "bundle" is sent/received atomically, at least for MI interface?

The MI protocol is more robust and there aren't such problems (the protocols returns the whole result in one line, there are tags, etc...).

[cbexaminr]

I understood almost nothing from your post...

sorry... prob. not worth re-attempting at this time...

The MI protocol is more robust and there aren't such problems (the protocols returns the whole result in one line, there are tags, etc...).

Unclear -
Could the MI protocol implementation stand to benefit from your speed up attempts, if a "safe" version of it could be "found"?
Or has a similar level of performance improvement (to your attempted patch in trunk) already come from the use of the MI protocol (in the wxprogrid_debugger branch)?

(In other thread, you seemed to indicate the slowness is still there when you referenced this thread, so didn't know if the "such problems" included improved performance, or merely avoidance of line-ending issues...?)

[oBFusCATed]

The MI protocol has some advantages to the normal protocol:
1. it is asynchronous protocol - you can send multiple commands and process the output for every command when it is ready
2. the result from a command is one long line of text (most of the time), so the wx events sent from the PipedProcess is 1 event per command not N events per command as the normal protocol (this is the current performance problem)
3. the protocol is made to be useful to IDEs not humans, so it is very robust (no regex-s and such fragile operations)
4. you can query/update only the changed variables in the watches window (the current one updates all variables)....

So the GDB/MI plugin is pretty fast and I don't think it will benefit too much from the improvement related to the wx events.

The patch is not committed, because it is not reliable and it breaks the debugging. I think it could be made to work, but I've not tried lately...