On 2011-01-24 22:00, Anthony Liguori wrote:
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> 
> diff --git a/cpus.c b/cpus.c
> index 9cf7e6e..0f8e33b 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -321,8 +321,8 @@ void vm_stop(int reason)
>  
>  #include "qemu-thread.h"
>  
> -QemuMutex qemu_global_mutex;
> -static QemuMutex qemu_fair_mutex;
> +GStaticMutex qemu_global_mutex;
> +static GStaticMutex qemu_fair_mutex;
>  
>  static QemuThread io_thread;
>  
> @@ -416,9 +416,9 @@ int qemu_init_main_loop(void)
>      qemu_cond_init(&qemu_system_cond);
>      qemu_cond_init(&qemu_pause_cond);
>      qemu_cond_init(&qemu_work_cond);
> -    qemu_mutex_init(&qemu_fair_mutex);
> -    qemu_mutex_init(&qemu_global_mutex);
> -    qemu_mutex_lock(&qemu_global_mutex);
> +    g_static_mutex_init(&qemu_fair_mutex);
> +    g_static_mutex_init(&qemu_global_mutex);
> +    g_static_mutex_lock(&qemu_global_mutex);
>  

Just replacing our own abstraction with glib's looks like a step in the
wrong direction. From a first glance at that library and its semantics
it has at least two major drawbacks:

 - Error handling of things like g_mutex_lock or g_cond_wait is, well,
   very "simplistic". Once we start to use more sophisticated locking,
   more bugs will occur here, and we will need more support than glib is
   able to provide (or can you control error handling elsewhere?).

 - GMutex is not powerful enough for optional things like PI mutexes -
   which is required once we want to schedule parts of qemu with RT
   priorities (I did it, it works surprisingly well).

The same concerns apply to other abstractions glib provides for
threading and synchronization. One may work around them, but that will
break abstractions again.

Glib seems to fit standard use case quite comfortably but fails in more
advanced scenarios qemu is already useable for (just lacking a few
additional lines of code).

In short: we need full POSIX where available.

Jan