From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Stancek Date: Tue, 28 Aug 2018 10:38:47 -0400 (EDT) Subject: [LTP] [PATCH v2 1/2] lib: add tst_get_timeout() In-Reply-To: <87wosashbp.fsf@rpws.prws.suse.cz> References: <6680bda80c85d424a5219d9f55dc9c5355dc0da1.1535454204.git.jstancek@redhat.com> <20180828125808.GB24095@rei> <87wosashbp.fsf@rpws.prws.suse.cz> Message-ID: <1445215680.43198555.1535467127164.JavaMail.zimbra@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it ----- Original Message ----- > Hello, > > Cyril Hrubis writes: > > > Hi! > > It's just an idea, but we can make this even more elegant API. > > > > We measure the time in the test library anyway, so what about we added > > something as tst_timeout_reached() that would return number of seconds > > remaining to 80% of the real timeout or 0 if in a case that the timeout > > was reached. Then we can use this as a soft-timeout in all the testcases > > without any additional steps. > > > > -- > > Cyril Hrubis > > chrubis@suse.cz > > 80% is probably way more than many of the CVE test cases need unless the > overall timeout is reduced from 5 minutes. Probably 20% would be > OK. Assuming this is the kind of usage scenario you had in mind. I'd leave it to user. Give him data how much time is left, and let him decide what is sensible limit for soft-timeout. I'll send example in v3 series shortly. > > We could also call it tst_timeout_approaching, tst_timeout_near or > tst_time_to_fail... not sure if they are any better. > > -- > Thank you, > Richard. >