From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 1/3] epoll_wait/epoll_wait01.c: add new testcase
Date: Wed, 24 Feb 2016 17:11:18 +0100 [thread overview]
Message-ID: <20160224161118.GF8292@rei> (raw)
In-Reply-To: <1455706286-4090-1-git-send-email-fenggw-fnst@cn.fujitsu.com>
Hi!
Pushed with minor changes. Thanks.
> +static int get_writesize(void)
> +{
> + int nfd, write_size;
> + char buf[4096];
> +
> + memset(buf, 'a', sizeof(buf));
> +
> + struct pollfd pfd[] = {
> + {.fd = fds[0], .events = POLLIN},
> + {.fd = fds[1], .events = POLLOUT},
> + };
> +
> + write_size = 0;
> + do {
> + write_size += SAFE_WRITE(cleanup, 0, fds[1], buf, sizeof(buf));
> + nfd = poll(pfd, 2, -1);
> + if (nfd == -1)
> + tst_brkm(TBROK | TERRNO, cleanup, "poll failed");
> + } while (nfd == 2);
I've removed the fds[0] from the pollfd structure and instead of that
changed the poll() to have 1 ms timeout. Since making sure that it
returns on timeout is less confusing than making sure the poll returns
because we passed another file descriptor that has some data to be
read...
> + char read_buf[write_size];
> +
> + SAFE_READ(cleanup, 1, fds[0], read_buf, sizeof(read_buf));
> +
> + return write_size;
> +}
...
> +static int has_event(struct epoll_event *epevs, int epevs_len,
> + int fd, uint32_t events)
> +{
> + int i, result;
> +
> + result = 0;
> + for (i = 0; i < epevs_len; i++) {
> + if ((epevs[i].data.fd == fd) && (epevs[i].events == events)) {
> + result = 1;
> + break;
> + }
> + }
> +
> + return result;
> +}
And simplified this part to:
...
{
int i;
for (i = 0; i < epevs_len; i++) {
if ((epevs[i].data.fd == fd) && (epevs[i].events == events))
return 1;
}
return 0;
}
--
Cyril Hrubis
chrubis@suse.cz
prev parent reply other threads:[~2016-02-24 16:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-30 10:44 [LTP] [PATCH 1/3] epoll_wait/epoll_wait01.c: add new testcase Guangwen Feng
2015-12-30 10:44 ` [LTP] [PATCH 2/3] epoll_wait/epoll_wait02.c: " Guangwen Feng
2016-01-28 16:35 ` Cyril Hrubis
2015-12-30 10:44 ` [LTP] [PATCH 3/3] epoll_wait/epoll_wait03.c: " Guangwen Feng
2016-01-28 17:16 ` Cyril Hrubis
2016-01-06 1:19 ` [LTP] [PATCH 4/4] epoll_wait/epoll_wait04.c: " Guangwen Feng
2016-01-28 17:24 ` Cyril Hrubis
2016-01-28 16:19 ` [LTP] [PATCH 1/3] epoll_wait/epoll_wait01.c: " Cyril Hrubis
2016-02-01 5:28 ` Guangwen Feng
2016-02-17 10:51 ` [LTP] [PATCH v2 " Guangwen Feng
2016-02-17 10:51 ` [LTP] [PATCH v2 2/3] epoll_wait/epoll_wait02.c: " Guangwen Feng
2016-02-25 12:37 ` Cyril Hrubis
2016-02-17 10:51 ` [LTP] [PATCH v2 3/3] epoll_wait/epoll_wait03.c: " Guangwen Feng
2016-02-25 13:52 ` [LTP] [PATCH v2 3/3] llistxattr/llistxattr03.c: " Cyril Hrubis
2016-02-24 16:11 ` Cyril Hrubis [this message]
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=20160224161118.GF8292@rei \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox