[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH 0/4] RFC: make chardev context switching safer

From: Marc-André Lureau
Subject: [Qemu-devel] [PATCH 0/4] RFC: make chardev context switching safer
Date: Wed, 20 Feb 2019 17:06:24 +0100


The chardev context switching code is a bit fragile, as it works as if
the current context is properly synchronized with the new context.  It
isn't so obvious to me that concurrent usage of chardev can't happen,
as there might be various main loop sources being dispatched during
the switch.

Worried about the situation, I wrote those patches a while ago, I
think they are still worth to consider. I used to have some basic
test, but it now conflicts a lot with recent changes. I would like to
get some feedback about the series before I rewrite it.

The importat patch is "chardev: make qemu_chr_fe_set_handlers()
context switching safer". It works by "freezing" the given contexts
while the chardev will "move" (recreate to the new context) the
various sources it owns. This looks quite ugly to me overall, but still
safer than today.

This should allow to simplify the scary code from "monitor: set the
chardev context from the main context/thread".

Finally, "char-socket: restart the reconnect timer to switch context"
shows that we have chardev backends that do not switch fully yet.

(there should be a meme "using chardev from multiple threads is
considered harmful")

Marc-André Lureau (4):
  iothread: wait until the glib context is acquired
  chardev: make qemu_chr_fe_set_handlers() context switching safer
  monitor: set the chardev context from the main context/thread
  char-socket: restart the reconnect timer to switch context

 include/chardev/char-fe.h |  23 +++++++++
 chardev/char-fe.c         | 103 +++++++++++++++++++++++++++++++++-----
 chardev/char-mux.c        |  14 +++---
 chardev/char-socket.c     |   5 ++
 iothread.c                |   7 +++
 monitor.c                 |  39 +++------------
 6 files changed, 139 insertions(+), 52 deletions(-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]