From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.74) (envelope-from ) id 1PsvJG-0008Fu-Eo for ltp-list@lists.sourceforge.net; Fri, 25 Feb 2011 10:54:06 +0000 Received: from service87.mimecast.com ([94.185.240.25]) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.74) id 1PsvJF-0005nd-6Q for ltp-list@lists.sourceforge.net; Fri, 25 Feb 2011 10:54:06 +0000 From: "Will Deacon" References: <1297088926-21505-1-git-send-email-will.deacon@arm.com> <9151393516569896904@unknownmsgid> In-Reply-To: Date: Fri, 25 Feb 2011 10:53:48 -0000 Message-ID: <000901cbd4da$4a2949d0$de7bdd70$@deacon@arm.com> MIME-Version: 1.0 Content-Language: en-gb Subject: Re: [LTP] [PATCH] Fix rt_sigtimedwait ordering test List-Id: Linux Test Project General Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-list-bounces@lists.sourceforge.net To: 'Garrett Cooper' Cc: ltp-list@lists.sourceforge.net Hi Garrett, > > I've not heard anything further on this, but it does fix a real issue > > on the platform I'm using. Do you need anything more from me for this > > to be considered for committing? > > Kind of odd that only doing it there would fix the entire testcase > as that's not the only pattern of > > create_sig_proc(...) > > that isn't handled with a wait/waitpid. It's not that strange because, in this testcase at least, we call sigwaitinfo either with a timeout or a sigset_t in the parent. In the latter case this will block until the signal is delivered so the race between child and parent isn't a problem. > It just seems like there are tons of bugs lurking under the scenes > with this create_sig_proc deal because it doesn't wait, and if the > parent doesn't wait, then you're just creating a ton of races > potentially if not handled properly. The issue is when you have multiple children and the test relies on a specific ordering of signal delivery (as is the case for RT signals). > FWIW some more synchronization may need to be added in > create_sig_proc (like blocking I/O with a pipe for instance, mq_*, > sem_*? mq_* and sem_* are kind of undesirable though because those > APIs are buggy on different architectures / versions of Linux, and > pipes are generally simple enough to express synchronization), in > order to ensure that things are deterministically ordered and the > results of the test are sane. I'm not sure this is necessary because it restricts the concurrency for testcases where the race shouldn't matter. Will ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list