On Thu, Nov 13, 2014 at 07:26:10PM +0100, Marc-André Lureau wrote:
On Thu, Nov 13, 2014 at 6:38 PM, Christophe Fergeau cferg...@redhat.com
wrote:
Hey,
On Thu, Nov 13, 2014 at 05:41:20PM +0100, Marc-André Lureau wrote:
On Thu, Nov 13, 2014 at 10:07 AM, Christophe Fergeau
On Fri, Nov 14, 2014 at 10:59 AM, Christophe Fergeau cferg...@redhat.com
wrote:
Hmm I only partially understood what your log meant, and tried to
improve it, but it's very partial. I think it's better to be explicit
about main context/coroutine context here, maybe something like
During
On Fri, Nov 14, 2014 at 12:06:30PM +0100, Marc-André Lureau wrote:
On Fri, Nov 14, 2014 at 10:59 AM, Christophe Fergeau cferg...@redhat.com
wrote:
Hmm I only partially understood what your log meant, and tried to
improve it, but it's very partial. I think it's better to be explicit
about
On Wed, Nov 12, 2014 at 06:49:50PM +0100, Marc-André Lureau wrote:
On Wed, Nov 12, 2014 at 6:35 PM, Christophe Fergeau cferg...@redhat.com
wrote:
'git grep spice_channel_disconnect' gives:
doc/reference/spice-gtk-sections.txt:spice_channel_disconnect
gtk/channel-main.c:
On Wed, Nov 12, 2014 at 05:56:26PM +0100, Marc-André Lureau wrote:
On Wed, Nov 12, 2014 at 5:08 PM, Christophe Fergeau cferg...@redhat.com
wrote:
Rereading the commit log,
this movement seems unrelated to what you are fixing anyway?
It is related, since we change the state to
On Thu, Nov 13, 2014 at 10:07 AM, Christophe Fergeau cferg...@redhat.com
wrote:
Ah, this is the bit I was missing thanks! The commit log needs to be
much more detailed and accurate, and mention explicitly the various code
paths involved to trigger the error, where the looping occurs, ...
Hey,
On Thu, Nov 13, 2014 at 05:41:20PM +0100, Marc-André Lureau wrote:
On Thu, Nov 13, 2014 at 10:07 AM, Christophe Fergeau cferg...@redhat.com
wrote:
Ah, this is the bit I was missing thanks! The commit log needs to be
much more detailed and accurate, and mention explicitly the various
On Thu, Nov 13, 2014 at 04:43:26PM +0100, Marc-André Lureau wrote:
On Thu, Nov 13, 2014 at 10:15 AM, Christophe Fergeau cferg...@redhat.com
wrote:
It seems it could have stayed in the same place, but with the check
changed to _CONNECTING instead of != UNCONNECTED?
It is not the same
On Thu, Nov 13, 2014 at 6:38 PM, Christophe Fergeau cferg...@redhat.com
wrote:
Hey,
On Thu, Nov 13, 2014 at 05:41:20PM +0100, Marc-André Lureau wrote:
On Thu, Nov 13, 2014 at 10:07 AM, Christophe Fergeau
cferg...@redhat.com
wrote:
Ah, this is the bit I was missing thanks! The commit
On Sun, Nov 09, 2014 at 05:31:38PM +0100, Marc-André Lureau wrote:
During migration, the main channel initiating the process is waiting on
connection completion or error. However, if the migration is cancelled,
but the main channel state is still NONE, no error event will be fired,
and the
- Original Message -
On Sun, Nov 09, 2014 at 05:31:38PM +0100, Marc-André Lureau wrote:
During migration, the main channel initiating the process is waiting on
connection completion or error. However, if the migration is cancelled,
but the main channel state is still NONE, no
On Wed, Nov 12, 2014 at 5:08 PM, Christophe Fergeau cferg...@redhat.com
wrote:
Rereading the commit log,
this movement seems unrelated to what you are fixing anyway?
It is related, since we change the state to connecting before requesting
the fd, but we want to keep a warning when calling
On Wed, Nov 12, 2014 at 11:27:28AM -0500, Marc-André Lureau wrote:
- Original Message -
On Sun, Nov 09, 2014 at 05:31:38PM +0100, Marc-André Lureau wrote:
During migration, the main channel initiating the process is waiting on
connection completion or error. However, if the
- Original Message -
On Wed, Nov 12, 2014 at 11:27:28AM -0500, Marc-André Lureau wrote:
- Original Message -
On Sun, Nov 09, 2014 at 05:31:38PM +0100, Marc-André Lureau wrote:
During migration, the main channel initiating the process is waiting on
connection
On Wed, Nov 12, 2014 at 12:13:07PM -0500, Marc-André Lureau wrote:
- Original Message -
On Wed, Nov 12, 2014 at 11:27:28AM -0500, Marc-André Lureau wrote:
- Original Message -
On Sun, Nov 09, 2014 at 05:31:38PM +0100, Marc-André Lureau wrote:
During
During migration, the main channel initiating the process is waiting on
connection completion or error. However, if the migration is cancelled,
but the main channel state is still NONE, no error event will be fired,
and the main channel will remain frozen.
Setting connecting state before
16 matches
Mail list logo
