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"):
> Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote: 
> > 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. 
> 
> with log and gdb, i could see above flow except the ao in 
> egc->aops_for_callback is empty.

The ao is "empty" ?  I don't follow.

> and from gdb i could know that the egc is different between 
> libxl__ao_complete_check_progress_reports and fd event(here is 
> watchfd_callback).
> libxl__ao_complete_check_progress_reports
> (gdb) p egc
> $1 = (libxl__egc *) 0x7fb1fd03f500
> 
> watchfd_callback
> (gdb) p egc
> $4 = (libxl__egc *) 0x7ffffb291960

Every entry into libxl's event system has its own egc.  So if you are
entering two of these functions at once on different threads, each
will have its own egc.

> after check the code in libxl_osevent_occurred_fd, the egc is
> created in watchfd_callback.

No, watchfd_callback doesn't create the egc.  The EGC_GC macro doesn't
create the egc.  It only extracts the gc from it for the benefit of
code inside that function.  The egc will have been passed to
watchfd_callback from its caller.  The caller might be
afterpoll_internal called from libxl_osevent_afterpoll (but you imply
you're not using that) or from eventloop_iteration, which might be
called from libxl_event_wait (which you're not using) or
libxl__ao_inprogress (but only in the synchronous case which you're
not using).  Or it might be libxl_osevent_occurred_fd, which does
create the egc but runs the callbacks on exit.

> so, EGC_FREE could not handle the ao added by
> libxl__ao_complete_check_progress_reports. the latter egc is created
> by AO_CREATE in do_domain_create.  is it correct? if so, could we
> use the same egc all the time?

No, each egc corresponds to one entry into libxl.  That's what they're
for.

> here is the full libxl.log:

This shows only one ao.  Is that right ?  It starts here:

> libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x7fb1d0001e50: 
> create: how=0x7fb1f6448e80 callback=0x7fb1f6210fb0 poller=(nil)

And then, later, it completes:

> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x7fb1d0001e50: 
> complete, rc=0
> libxl: debug: libxl_event.c:1599:libxl__ao_complete_check_progress_reports: 
> ao 0x7fb1d0001e50: complete for callback
> libxl: debug: libxl_event.c:1173:egc_run_callbacks: ao 0x7fb1d0001e50: 
> completion callback
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x7fb1d0001e50: 
> destroy

Here we see the callback being made.  That message "completion
callback" comes from this code in egc_run_callbacks:

        LOG(DEBUG,"ao %p: completion callback", ao);
        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);

So this debug trace appears to show the callback actually happening.
What makes you think it isn't ?

Thanks,
Ian.

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