Re: [PATCH] Bail out of processing stop if hook-stop resumes target / changes context

[Pedro Alves <palves at redhat dot com>]

On 09/11/2015 03:55 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> We don't have infrastructure to run command lists like that.  The
>> hook-stop might involve several execution commands, for
>> instance.  See:
>>  https://sourceware.org/ml/gdb-patches/2011-09/msg00037.html
>> And what motivated it:
>>  https://sourceware.org/ml/gdb-patches/2011-06/msg00158.html
> 
> Yeah, I didn't strongly believe we have such infrastructure, so I raised
> that question.

OK.  I've pushed the patch in as is now.

> 
>>
>> I don't currently see any real benefit in splitting interpreter
>> command execution to a bigger and more complicated state machine
>> like I was originally attempting.  I've been thinking that longer
>> term, it'd be simpler/saner if we split run control and the
>> interpreter to separate threads.  I actually have a prototype
> 
> It sounds natural to move interpreter and run control to separate
> threads.  It may be hard to convert single-threaded gdb to a
> multi-threaded version.  

I took the giant lock approach [1].  I added a big gdb lock around the
event loop's select/poll calls.  That is, at any given time, there's only
really one thread not blocked in select/poll calling into gdb handling
an event.  This gives us a stack per interpreter, which is what I was after.
For true parallelism, my idea was to then break the big lock into
finer-brained locks, incrementally, as needed.  Not unlike e.g. how Linux's
BKL was eliminated.

[1] https://en.wikipedia.org/wiki/Giant_lock

> Note that I am not against this direction.

Great.

Thanks for the review.

-- 
Pedro Alves