This is the mail archive of the rda@sourceware.org mailing list for the rda 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: [RFC] Improve performance of multi-threaded debugging


Kevin Buettner <kevinb@redhat.com> writes:
> On Fri, 16 Sep 2005 13:19:57 -0700
> Jim Blandy <jimb@redhat.com> wrote:
>
>> 
>> Kevin Buettner <kevinb@redhat.com> writes:
>> > The only fly in the ointment is that the signal based event model only
>> > knows about thread creation, but not about thread death.  So it won't
>> > catch thread death until some new thread is created.  I'm not sure
>> > what the implications of this are in practice.
>> 
>> Even in the signal-based model, we're attached to all the threads, so
>> we should get a wait status via lwp_pool_waitpid.  Isn't that working?
>
> It probably does, but do not know for certain.
>
> I saw that the thread list was getting fetched on every status check.  My
> assumption was that there was some good reason for this to occur and revised
> the code so that it would only happen when so informed by the event model.
> What I did not investigate is whether the thread refetch ever really needs
> to happen at all.

Well, that's a bigger question than the one I was thinking about.  You
wrote that you were concerned about missing thread death events, and I
was saying that I thought that wouldn't happen.

It would be nice to look at the larger question of whether we need to
re-transfer the list at all, or whether we could just let TD_CREATE
and TD_DEATH maintain it.  Something makes me a little uncomfortable
with an "edge-sensitive" model over a "level-sensitive" model, but I
can't see anything wrong with it.


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