This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 09/11/2015 03:55 PM, Yao Qi wrote:
> Pedro Alves <> writes:
>> We don't have infrastructure to run command lists like that.  The
>> hook-stop might involve several execution commands, for
>> instance.  See:
>> And what motivated it:
> 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.


> Note that I am not against this direction.


Thanks for the review.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]