From: Marcelo Tosatti <mtosatti@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [patch 04/10] qemu: introduce main_loop_break
Date: Thu, 2 Apr 2009 20:36:21 -0300 [thread overview]
Message-ID: <20090402233621.GA4599@amt.cnet> (raw)
In-Reply-To: <20090326122717.GB20866@shareable.org>
On Thu, Mar 26, 2009 at 12:27:17PM +0000, Jamie Lokier wrote:
> Marcelo Tosatti wrote:
> > Use a pipe to signal pending work for the iothread.
>
> > +void main_loop_break(void)
> > +{
> > + uint64_t value = 1;
> > + char buffer[8];
> > + size_t offset = 0;
> > +
> > + if (io_thread_fd == -1)
> > + return;
> > +
> > + memcpy(buffer, &value, sizeof(value));
> > +
> > + while (offset < 8) {
> > + ssize_t len;
> > +
> > + len = write(io_thread_fd, buffer + offset, 8 - offset);
> > + if (len == -1 && errno == EINTR)
> > + continue;
> > +
> > + if (len <= 0)
> > + break;
> > +
> > + offset += len;
> > + }
> > +
> > + if (offset != 8)
> > + fprintf(stderr, "failed to notify io thread\n");
>
> 1: Why do you write 8 bytes instead of 1 byte? If you're thinking of
> passing a value at some point, you could change it later when it's
> needed. But beware that requiring the pipe to hold all values
> written is what made Netscape 4 lock up on too-new Linux kernels
> some 10 years ago :-)
>
> 2: Do you know that writes <= PIPE_BUF are atomic so you don't need
> the offset calculation?
I didnt know. Anthony wrote this code, so I'll let him comment.
> > +/* Used to break IO thread out of select */
> > +static void io_thread_wakeup(void *opaque)
> > +{
> > + int fd = (unsigned long)opaque;
> > + char buffer[8];
> > + size_t offset = 0;
> > +
> > + while (offset < 8) {
> > + ssize_t len;
> > +
> > + len = read(fd, buffer + offset, 8 - offset);
> > + if (len == -1 && errno == EINTR)
> > + continue;
> > +
> > + if (len <= 0)
> > + break;
> > +
> > + offset += len;
> > + }
> > +}
>
> You should read until the pipe is empty, in case more than one signal
> was raised and called main_loop_break() between calls to
> io_thread_wait().
>
> Since reads <= PIPE_BUF are atomic too, the easiest way to do that is
> try to read at least one more byte than you wrote per
> main_loop_break() call, and if you don't get that many, you've emptied
> the pipe.
>
> > +static void setup_iothread_fd(void)
> > +{
> > + int fds[2];
> > +
> > + if (pipe(fds) == -1) {
> > + fprintf(stderr, "failed to create iothread pipe");
> > + exit(0);
> > + }
> > +
> > + qemu_set_fd_handler2(fds[0], NULL, io_thread_wakeup, NULL,
> > + (void *)(unsigned long)fds[0]);
> > + io_thread_fd = fds[1];
> > +}
>
> To avoid deadlock in perverse conditions where lots of signals call
> main_loop_break() enough to fill the pipe before it's read, set the
> write side non-blocking.
The pipe is set nonblocking by a later patch. Perhaps the hunk should be
part of this patch.
> To use the trick of reading more bytes than you expect to detect EOF
> without an extra read, set the read side non-blocking too.
next prev parent reply other threads:[~2009-04-02 23:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 22:47 [Qemu-devel] [patch 00/10] iothread (candidate for inclusion) Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 01/10] qemu: create helper for event notification Marcelo Tosatti
2009-03-25 23:18 ` Glauber Costa
2009-03-25 23:27 ` Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 02/10] qemu: mutex/thread/cond wrappers Marcelo Tosatti
2009-03-25 23:24 ` Glauber Costa
2009-03-25 23:29 ` Marcelo Tosatti
2009-03-26 11:01 ` malc
2009-03-25 22:47 ` [Qemu-devel] [patch 03/10] qemu: per-arch cpu_has_work Marcelo Tosatti
2009-03-25 23:26 ` Glauber Costa
2009-03-28 18:14 ` Blue Swirl
2009-03-29 20:13 ` Blue Swirl
2009-04-02 23:42 ` Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 04/10] qemu: introduce main_loop_break Marcelo Tosatti
2009-03-26 1:24 ` Glauber Costa
2009-03-26 12:27 ` Jamie Lokier
2009-04-02 23:36 ` Marcelo Tosatti [this message]
2009-04-02 23:52 ` Anthony Liguori
2009-04-03 14:08 ` Markus Armbruster
2009-04-07 3:23 ` Jamie Lokier
2009-03-25 22:47 ` [Qemu-devel] [patch 05/10] qemu: separate thread for io Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 06/10] qemu: per-cpu thread information Marcelo Tosatti
2009-03-26 1:35 ` Glauber Costa
2009-03-26 2:10 ` Marcelo Tosatti
2009-03-26 2:26 ` Glauber Costa
2009-03-26 2:41 ` Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 07/10] qemu: handle reset/poweroff/shutdown in iothread Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 08/10] qemu: pause and resume cpu threads Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 09/10] qemu: handle vmstop from cpu context Marcelo Tosatti
2009-03-25 22:47 ` [Qemu-devel] [patch 10/10] qemu: basic kvm iothread support Marcelo Tosatti
2009-03-29 20:16 ` [Qemu-devel] [patch 00/10] iothread (candidate for inclusion) Blue Swirl
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=20090402233621.GA4599@amt.cnet \
--to=mtosatti@redhat.com \
--cc=jamie@shareable.org \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).