From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: msnyder@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFA] Clean up spurious SIGSTOPS in lin-lwp Date: Sat, 26 May 2001 02:15:00 -0000 Message-id: <200105260915.f4Q9Fik00295@delius.kettenis.local> References: <3B0EE363.DA047C1B@cygnus.com> X-SW-Source: 2001-05/msg00475.html Date: Fri, 25 May 2001 15:57:39 -0700 From: Michael Snyder Mark, This patch will get rid of most of those "Delayed SIGSTOP" messages, so that lin_lwp_wait will rarely if ever get a SIGSTOP that was generated by gdb. It entails three basic changes: * In lin_lwp_attach_lwp, consume the SIGSTOP that is generated by PTHREAD_ATTACH. * In stop_wait_callback, try again to consume the SIGSTOP after "pushing back" a SIGTRAP for a thread other than the event thread. * Similarly try again to consume a SIGSTOP after tossing away a redundant SIGINT. In principle the current approach saves us a few system calls, at the risk of a GDB-generated SIGSTOP colliding with a SIGSTOP that wasn't generated by GDB. I assume you're trying to make GDB behave a little better when some outside agency is generating SIGSTOPs. We have to keep in mind that as long as SIGSTOP doesn't have Real-Time semantics, we can never guarantee that things work entirely reliably. The question is whether we prefer the situation where things clearly don't work correctly if SIGSTOP is used in the user program (as we have now, although I'm not sure about that "clearly"), or that we'd rather have things more or less working correctly, but fail in some corner cases only. The change to lin_lwp_attach_lwp is a change from for every thread send out message for every thread collect response to for every thread send out message collect response In theory this could make the process slower, making attaching even more non-atomic than it is already. But we hardly ever attach to more than one or two LWP's at the same time (only when attaching to an already running threaded program) so that shouldn't really matter. So if this change represents a real improvement in GDB's behaviour I think it's OK. Mark