Hi,
--- On Fri, 1/16/09, Garrett Cooper <yaneg...@gmail.com> wrote: > From: Garrett Cooper <yaneg...@gmail.com> > Subject: Re: [LTP] [PATCH] sched_cli_serv: client: connect failure, no = 111 > v2 > To: caiq...@cclom.cn > Cc: ltp-l...@lists.sf.net > Date: Friday, January 16, 2009, 3:39 PM > On Thu, Jan 15, 2009 at 11:25 PM, CAI Qian > <caiq...@cclom.cn> wrote: > > Hi, > > > > Sometimes, sched_cli_serv test case can still fail due > to, > > > > client: connect failure, no = 111 > > > > This is because when the system is under load, the > client may connect > > before the server is ready. This patch fixes it by > letting the server > > run for 10 seconds first. It also disable shell > command tracing by > > default which was accidentally introduced by the last > patch, > > > > http://article.gmane.org/gmane.linux.ltp/7149 > > > > Signed-off-by: CAI Qian <caiq...@cclom.cn> > > > > --- > ltp-full-20081031/testcases/kernel/sched/clisrv/run_sched_cliserv.sh.orig > 2009-01-16 11:12:49.821546689 +0800 > > +++ > ltp-full-20081031/testcases/kernel/sched/clisrv/run_sched_cliserv.sh > 2009-01-16 11:13:18.935562956 +0800 > > @@ -1,6 +1,7 @@ > > -#!/bin/sh -x > > +#!/bin/sh > > > > pthserv & > > +sleep 10 > > pthcli 127.0.0.1 $LTPROOT/testcases/bin/data > > clientCode=$? > > killall pthserv > > Sorry for interjecting, but I don't like hacks like > this; there are > some bad decisions like this that occur in my everyday > work, and in > order to make everything magically work the timeout keeps > on growing, > instead of the components working together with some level > of > cohesion. A better idea: make pthserv and pthcli more > forgiving in > terms of timeouts in their respective codebases, so that > they're more > robust when it comes to latency issues when connecting. > > Should be simple to implement -- add a counter and a loop / > condition > at the top of a loop to wait for the connection to occur or > fail. > > If you want I'll write up the required changes in C. > Yes, it is a hack indeed. The patch was to quickly workaround the original false negative, and also make it reasonable robust. I am happy to test and review your version though. CAI Qian > Cheers, > -Garrett ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
