Re: [PATCH] gdb: unbuffer all input streams when not using readline

[Simon Marchi <simon.marchi@polymtl.ca>]

>> How difficult would it be to just have different behaviors on Windows,

>>

>> opening the stream only once, vs Linux, opening three streams?

> 

> I think it would be easy enough to implement new-ui differently for

> unix vs for windows.

> 

> But, if I've left you with the impression that this is a possible

> solution, then I failed with my commit message.  Even on Linux, when

> we're not using new-ui at all, we currently can loose commands unless

> we switch to unbuffered input.



No, you did mention it, my bad.



> Another option; maybe there's some ioctl that can be used to tell the

> kernel that a newline at the start of a read request should be

> considered a line break.  However, if such an ioctl exits, I've failed

> to find it.

> 

> The final option that I considered is to place glibc into unbuffered

> mode, and then do the buffering ourselves within gdb.  This obviously

> adds a load more complexity which is why I'd rather not do this.

> 

> But, if we did do this, then at the end of

> gdb_readline_no_editing_callback we could set the flag

> call_stdin_event_handler_again_p, and things would "just work".



Yes, I think that would make sense.  Instead of using

call_stdin_event_handler_again_p, I would use a event in the event loop

(using create_async_event_handler) for that.  That means we go back to

the event loop, so it's fair for the other event sources, versus

call_stdin_event_handler_again_p which is a tight loop.



> I can take a look at gathering some performance figures for sure and

> will update once I have some data, but this patch is fixing an

> existing bug...



Yeah, so I am in favor of merging this patch and then looking if

re-enabling some buffering is desirable.  The important thing is the

test that you had, which will hopefully prevent introducing a similar

bug.



Simon