Re: [PATCH v2 2/4] replay: remove a message that could be caused by a race condition

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

 



On Wed, 2016-02-03 at 10:48 +0000, Frediano Ziglio wrote:
> The req_cmd_notification callback is called by spice-server when it
> has processed all commands and wants to be notified (by a wakeup) that
> new commands have been appended to the command queue.
> Replay utility tries to fill the commands when it detects that
> spice-server is trying to read commands but there are no more commands.
> However, new commands are appended of new commands happen in a separate

s/of new commands happen//

> thread so if the main red worker loop on spice-server is really tight
> this request can happen.
> Avoid printing any message on this condition, message will be appended
> and loop woken up when replay code can do it.
> 
> Signed-by: Frediano Ziglio <figlio@xxxxxxxxxx>

Ack with change above

Acked-by: Jonathon Jongsma <jjongsma@xxxxxxxxxx>

> ---
>  server/tests/replay.c | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/server/tests/replay.c b/server/tests/replay.c
> index c7f3f00..f3b670f 100644
> --- a/server/tests/replay.c
> +++ b/server/tests/replay.c
> @@ -183,12 +183,6 @@ static int get_command(QXLInstance *qin, QXLCommandExt
> *ext)
>  
>  static int req_cmd_notification(QXLInstance *qin)
>  {
> -    if (!started)
> -        return TRUE;
> -
> -    g_printerr("id: %d, queue length: %d",
> -                   g_source_get_id(fill_source),
> g_async_queue_length(aqueue));
> -
>      return TRUE;
>  }
>  
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]