From: Stefan Hajnoczi <stefanha@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC] contrib: add vhost-user-sim
Date: Wed, 9 Oct 2019 15:00:21 +0100 [thread overview]
Message-ID: <20191009140021.GQ5747@stefanha-x1.localdomain> (raw)
In-Reply-To: <24d18f1c38356b19461e77275b94a1ebf89838f1.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]
On Mon, Sep 23, 2019 at 11:33:41AM +0200, Johannes Berg wrote:
> On Mon, 2019-09-23 at 10:25 +0100, Stefan Hajnoczi wrote:
> Note, I'm not happy with this code at all, it deadlocks all the time.
> Unfortunately I haven't really been able to figure out how to make glib
> do what I wanted.
>
> The first issue is that sometimes glib actually seems to reports an FD
> as readable when it's not, so I even put them into non-blocking mode :(
Strange. Spurious wakeups are possible in general. I think when using
fd monitoring (select(), poll(), etc) the fds should be in non-blocking
mode.
But if you're seeing this often it makes me wonder if something else is
unintentionally reading available bytes...
> The second is that I can't seem to understand how to do recursive
> mainloops.
>
> To really do this *well*, it should remain a single-threaded
> application, but would need a hook like
>
> run_mainloop_until_fd_readable(vdev->call_fd)
>
> inside the libvhost-user.c code, and that's a bit ugly ... if I even
> could figure out how to implement that in glib.
Recursive mainloops are tricky since usually event loop code isn't
written to be re-entrant. It opens up a whole new dimension that
existing code usually wasn't designed for. In this case you are writing
the code from scratch so maybe you can get it to work, but it makes me
wonder why the recursive mainloop is necessary.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-09 19:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 12:26 [Qemu-devel] [RFC] contrib: add vhost-user-sim Johannes Berg
2019-09-17 18:51 ` no-reply
2019-09-17 19:01 ` no-reply
2019-09-17 19:02 ` no-reply
2019-09-23 9:25 ` Stefan Hajnoczi
2019-09-23 9:33 ` Johannes Berg
2019-10-09 14:00 ` Stefan Hajnoczi [this message]
2019-10-09 15:01 ` Johannes Berg
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=20191009140021.GQ5747@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=mst@redhat.com \
--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).