delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
X-SWARE-Spam-Status: | No, hits=-1.1 required=5.0 tests=AWL,BAYES_05,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL |
X-Spam-Check-By: | sourceware.org |
MIME-Version: | 1.0 |
In-Reply-To: | <CADqjQ-K_8jWgoBrqzVRk2xYY9GqyCsPk7YV+Em2c61SrBGnijg@mail.gmail.com> |
References: | <CADqjQ-+qMfy5EQ3cT2h__KoNMpxxZT+S1Kf=ahecS-33VYEm3Q AT mail DOT gmail DOT com> <CADqjQ-K_8jWgoBrqzVRk2xYY9GqyCsPk7YV+Em2c61SrBGnijg AT mail DOT gmail DOT com> |
Date: | Thu, 14 Jul 2011 19:29:32 -0400 |
Message-ID: | <CADqjQ-KpURz6--+reetjadCJDYuTPj=QE2km4Eg_3aKZtNNrSA@mail.gmail.com> |
Subject: | Re: Pthread question for GDB? |
From: | Jan Chludzinski <jan DOT chludzinski AT gmail DOT com> |
To: | cygwin AT cygwin DOT com |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Unsubscribe: | <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
> This has everything to do with the beast called parallelism and nothing to do with either > cygwin or gdb (which is probably why you're not getting replies). > > A short-running thread can easily complete before pthread_create returns. > > Here's the law of the jungle, as simply put as I know: other threads can and will do > *anything* they want, performing an arbitrary amount of work, in the time it > takes > the thread you're watching to execute a single machine instruction. Every time you > assume otherwise you *will* be disappointed. > > This applies whether you're single stepping in gdb or not. I've debugged pthreads before using GDB on Linux and Unix but GDB seemed to abide by: "whenever your program stops under gdb for any reason, all threads of execution stop, not just the current thread. This allows you to examine the overall state of the program, including switching between threads, without worrying that things change underfoot." (GDB manual) I've used condition variables before to create pthreads that are born sleeping (i.e., waiting for a condition variable to be signaled) but (under Linux and Unix) I've never had this problem of a thread finishing before I could even switch to it and start stepping. BTW, when there's different behavior between GDB (or any GNU dev tool) under Cygwin and Unix/Linux, I do believe that it's appropriate to post a question concerning this on the cygwin mailing list. ---Jan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |