[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded event waiting



Ian Campbell writes ("Re: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded 
event waiting"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > We also need to move some variables from globals in the ctx to be
> > per-polling-thread.
> 
> I don't think this relates to this patch, just that the mention of
> multithreaded waiting brought it to mind. What are the intended
> semantics of two calls to libxl_event_wait with overlapping event masks?

You get each event exactly once, via one of the (possibly several)
suitable libxl_event_wait calls.

> Do we expect that the caller must have called the appropriate evenables
> twice such that both waits get an event (possibly discriminate via the
> predicate)?

No.  Well, I guess the caller could do that by divvying up the ev_user
space between the two calls, but it would be a very perverse thing to
do.

> Presumably we want to ensure that one of the waits doesn't sleep for
> ever.

Yes, that's what the wakeup pipe is for.

> How does this interact with events generated via the hooks mechanism? Do
> we always deliver to the explicit wait in preference?

No.  As the doc comment for libxl_event_register_callbacks says:

   * Arranges that libxl will henceforth call event_occurs for any
   * events whose type is set in event_occurs_mask, rather than
   * queueing the event for retrieval by libxl_event_check/wait.
   * Events whose bit is clear in mask are not affected.

So if you ask for callbacks you don't get the events via wait.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.