Re: [Xen-devel] [PATCH 2/2] call ao_how callback explicitly

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Bamvor Jian Zhang writes ("Re: [Xen-devel] [PATCH 2/2] call ao_how callback 
explicitly"):
...
> > I'm not sure what you mean.  Under what conditions do you not see the
> > callback happen ?  The existing machinery is supposed to take care of
> > that.  Specifically, in the patch you're changing,
> > libxl__ao_complete_check_progress_reports puts the ao onto
> > egc->aos_for_callback.  On the return path from the libxl event
> > function back to the application, we are supposed to call
> > libxl__egc_cleanup, which in turn calls egc_run_callbacks, which
> > should pick up the aos on aos_for_callback.  libxl__egc_cleanup is
> > called from the event loops in libxl_event_wait and
> > libxl__ao_inprogress and from the macro EGC_FREE.  It should be
> > impossible for a path to be missed because inside libxl one needs an
> > egc to call libxl__ao_complete.
...
> the libvirt libxl driver register the event handler through
> libxl_event_register_callbacks,

Right.

> so the libxl_event_wait could not get the event.

I understand from this that you're calling libxl_event_wait ?  (Rather
than that you're saying that you're not calling libxl_event_wait, but
doing so wouldn't help.)

But, as I understand it, you're passing an ao_how which specifies a
callback, rather than the generation of an event.  So I think
libxl_event_wait is irrelevant.

> and if the ao_how is used, the libxl__egc_cleanup in
> "if ( poller )" statement will not be called either.
> even if i could expose the libxl_egc_cleanup to libvirt, i still do not
> know when should i call it?

No, you shouldn't need to call it explicitly and doing so won't help.

> i do not know if there is a event triggered
> before the ao_how callback should be called. (is there a fd event when
> the async operation complete?).

It's the other way around.  The async operation completes, probably,
because of an fd event.  So I think the call flow should be:

 1. Your application notices the fd is readable (say)
 2. Your application calls libxl_osevent_occurred_fd.
 3. libxl_osevent_occurred_fd allocates an egc on entry.
 4. In libxl, libxl_osevent_occurred_fd calls whatever internal
    functions are supposed to respond to the fd.  If appropriate,
    this will cause some ao to complete.  All of these calls
    will receive the same egc as created in step 3.  I.e.:
 5. In libxl, something calls libxl__ao_complete.
 6. libxl__ao_complete puts the ao on the egc's aos_for_callback
    list.
 7. The call stack unwinds inside libxl, eventually returning
    to libxl_osevent_occurred_fd.
 8. libxl_osevent_occurred_fd uses EGC_FREE on exit, and EGC_FREE
    contains a call to libxl__egc_cleanup.
 9. libxl__egc_cleanup calls egc_run_callbacks which finds the ao
    on the aos_for_callback list and makes your application
    callback.

The purpose of the "poller" machinery is so that if at step 5 we
decide to return an event structure, rather than making a callback, a
concurrent call to libxl_event_wait (on a different thread) can be
woken up.

Can you turn on libxl's debugging and send me a trace of it losing the
event ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel