All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <ian.jackson@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH v6.1 05/11] libxl_qmp: Implementation of libxl__ev_qmp_*
Date: Wed, 14 Nov 2018 17:07:30 +0000	[thread overview]
Message-ID: <23532.22098.906750.732501@mariner.uk.xensource.com> (raw)
In-Reply-To: <20181114163315.GL1302@perard.uk.xensource.com>

Anthony PERARD writes ("Re: [PATCH v6.1 05/11] libxl_qmp: Implementation of libxl__ev_qmp_*"):
> The current implementation already cleanup the broken state before the
> control is passed outside ev_qmp implementation. That result in the Idle
> public state. Whenever an internal function throw an error, it lets the
> main function qmp_ev_fd_callback taking care of cleanup the `broken` state
> so that when the control passes outside ev_qmp implementation the state
> is disconnected/Idle.

Ah right.

> An internal `broken` state is just an half-transition toward the
> disconnected/Idle state.
> 
> I guess I could add to the internal state documentation:
> 
>   When an internal function return an error, it can leave ev_qmp in a
>   `broken` state but only if the caller is another internal function.
>   That `broken` needs to be cleaned up, e.i. transitionned to the
>   `disconnected` state, before the control of ev_qmp is released
>   outsides of ev_qmp implementation.

If you do this you need to describe what kinds of states are legal
`broken' states.  This is probably must easily done by making the
`broken' state a proper first-class internal state (giving it an entry
in the state table), but stating, as you do above, that it is not
visible externally because it's always tidied into `disconnected'
before control passes outside ev_qmp.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-11-14 17:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 12:28 [PATCH v6.1 05/11] libxl_qmp: Implementation of libxl__ev_qmp_* Anthony PERARD
2018-11-13 13:14 ` Ian Jackson
2018-11-13 15:42   ` Anthony PERARD
2018-11-13 16:10     ` Ian Jackson
2018-11-14 11:40       ` Anthony PERARD
2018-11-14 15:43         ` Ian Jackson
2018-11-14 15:49           ` Ian Jackson
2018-11-14 16:33           ` Anthony PERARD
2018-11-14 17:07             ` Ian Jackson [this message]
2018-11-15 11:15               ` [PATCH v6.2 " Anthony PERARD
2018-11-15 18:40                 ` Ian Jackson
2018-11-16 14:53                   ` Anthony PERARD
2018-11-16 16:09                     ` Ian Jackson
2018-11-16 17:10                       ` Anthony PERARD
2018-11-16 18:16                         ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23532.22098.906750.732501@mariner.uk.xensource.com \
    --to=ian.jackson@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.