From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] Test library API changes
Date: Tue, 15 Mar 2016 10:22:26 +0100 [thread overview]
Message-ID: <20160315092226.GA26279@rei.lan> (raw)
In-Reply-To: <870463953.9758877.1458032315296.JavaMail.zimbra@redhat.com>
Hi!
> That it will only cause signal to be delivered to that thread,
> but handler will still kill entire process.
Ah, right. I tend to forget that part.
> We could use different signal and define a signal handler,
> that would just loop, but that still doesn't guarantee
> when pending signal is delivered. Also threads could mask
> the signal.
We can call a pause() in a loop from the signal handler and check that
the thread is sleeping in the kernel from the main thread. But this is
getting too complicated.
> Then I was thinking about blocking threads using affinity,
> but if test changed priority we could lock ourselves out.
>
> We do say in style guide, that cleanup can be called at any
> time. Should we leave it up to test author? We had the same
> problem with oldlib, right?
Yes, and technically we have the same problem with the forked processes
as well. When the main process calls tst_brk() the child processes may
still be running. But killing/waiting children in tst_brk() could be
done quite easily.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2016-03-15 9:22 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 11:11 [LTP] Test library API changes Cyril Hrubis
2016-01-07 13:01 ` Jan Stancek
2016-01-07 13:27 ` Cyril Hrubis
2016-02-04 10:56 ` Cyril Hrubis
2016-02-08 18:02 ` Cyril Hrubis
2016-02-09 16:43 ` Cyril Hrubis
2016-02-09 16:57 ` Cyril Hrubis
2016-02-09 17:46 ` Cyril Hrubis
2016-02-10 10:42 ` Jan Stancek
2016-02-10 10:56 ` Cyril Hrubis
2016-02-10 11:41 ` Cyril Hrubis
2016-02-11 16:03 ` Cyril Hrubis
2016-02-12 12:33 ` Jan Stancek
2016-02-12 17:53 ` Cyril Hrubis
2016-02-16 21:19 ` Cyril Hrubis
2016-02-17 14:39 ` Jan Stancek
2016-02-17 15:54 ` Cyril Hrubis
2016-02-18 9:05 ` Jan Stancek
2016-02-18 11:07 ` Cyril Hrubis
2016-02-18 11:26 ` Jan Stancek
2016-02-18 11:53 ` Cyril Hrubis
2016-03-02 14:44 ` Cyril Hrubis
2016-03-03 13:13 ` Jan Stancek
2016-03-03 14:00 ` Cyril Hrubis
2016-03-10 16:57 ` Cyril Hrubis
2016-03-11 13:57 ` Jan Stancek
2016-03-14 12:51 ` Cyril Hrubis
2016-03-14 16:00 ` Cyril Hrubis
2016-03-15 8:58 ` Jan Stancek
2016-03-15 9:22 ` Cyril Hrubis [this message]
2016-03-17 16:06 ` Cyril Hrubis
2016-03-18 9:44 ` Jan Stancek
2016-03-31 10:01 ` Cyril Hrubis
2016-04-01 14:45 ` Jan Stancek
2016-04-04 12:04 ` Cyril Hrubis
2016-04-04 14:12 ` Jan Stancek
2016-04-05 14:16 ` Cyril Hrubis
2016-04-05 15:06 ` Jan Stancek
2016-04-06 10:37 ` Cyril Hrubis
2016-03-14 16:40 ` Cyril Hrubis
2016-02-18 9:14 ` Alexey Kodanev
2016-02-18 10:40 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160315092226.GA26279@rei.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.