> On Jan 9, 2017, at 11:06 AM, Stefan Hajnoczi wrote:
>
> On Fri, Jan 06, 2017 at 10:22:56AM +0800, Peng Tao wrote:
>> On Tue, Dec 13, 2016 at 5:50 PM, Stefan Hajnoczi wrote:
>>> On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote:
Currently, if a connect call fails on a signal or tim
On Fri, Jan 06, 2017 at 10:22:56AM +0800, Peng Tao wrote:
> On Tue, Dec 13, 2016 at 5:50 PM, Stefan Hajnoczi wrote:
> > On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote:
> >> Currently, if a connect call fails on a signal or timeout (e.g., guest is
> >> still
> >> in the process of starti
On Tue, Dec 13, 2016 at 5:50 PM, Stefan Hajnoczi wrote:
> On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote:
>> Currently, if a connect call fails on a signal or timeout (e.g., guest is
>> still
>> in the process of starting up), we'll just return to caller and leave the
>> connect
>> pac
On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote:
> Currently, if a connect call fails on a signal or timeout (e.g., guest is
> still
> in the process of starting up), we'll just return to caller and leave the
> connect
> packet queued and they are sent even though the connection is consi
Currently, if a connect call fails on a signal or timeout (e.g., guest is still
in the process of starting up), we'll just return to caller and leave the
connect
packet queued and they are sent even though the connection is considered a
failure,
which can confuse applications with unwanted false
