Re: [PATCH] Don't send queries to the MI interpreter

[Simon Marchi <simon dot marchi at ericsson dot com>]

On 17-02-10 02:19 PM, Pedro Alves wrote:
> On 02/10/2017 07:05 PM, Simon Marchi wrote:
>> On 17-02-10 01:07 PM, Pedro Alves wrote:
> 
>>> So I think that to support multiple queries like that
>>> the simplest / most natural would be to make each
>>> UI above run on its own thread, so that each would have
>>> its own independent stack/frames.
>>
>> Indeed.  That represents a tremendous amount of work I imagine,
>> putting the proper locking mechanisms in place...  And if you
>> are holding a lock while the query is issued, it would still
>> block some other things.
> 
> I had it working with a GIL/BKL-style lock, in the original
> "new-console" prototype that was later rewritten into what
> is "new-ui" today.  I.e,. even though we'd have multiple
> threads, only one thread really runs at a time.  The idea
> was that we'd start with a big lock, and then over time break
> down the lock into more finer-grained locks.
> 
> Here:
> 
> https://github.com/palves/gdb/commits/palves/console-extra
> 
> - A thread per UI.  See the "Start a thread for each UI" patch.
> - Per-UI readline (with a giant readline hack)
> - Per-UI nurses/TUI instance (it really works!) :-)

And which thread handles inferior events?

> The trouble is that this then trips on another nasty problem:
> 
> All ptrace calls targeting a process must be issued
> from the thread that first attached to that inferior process.
> The kernel rejects the ptrace call otherwise eith EIO/EINVAL
> or some such, I don't recall which.  So on that branch, with
> native debugging, if you start the inferior on UI #1, and then
> try to read memory from UI #2, it fails...  If you instead
> try the same against gdbserver, it all works, because in that
> case gdbserver handles the ptrace calls, not gdb, so all
> ptrace calls come from the same thread in that case.
> So for native debugging, we'd need to marshall all ptrace
> requests through the same thread...

A PtraceService...  it starts to look just like CDT! :)