[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [BUG] xs.watch and xs.unwatch are unreliable
I've CC'ed some people who might have an idea whether they are replying on this behaviour. I doubt that but let's better be sure... On Tue, Mar 01, 2016 at 11:17:54PM +0300, Sergei Lebedev wrote: > Hi list, > > I’ve initially wanted to report another inconsistency in ``xen.lowlevel.xs`` > documentation, but this time the issue is more subtle. > > Both ``xs.watch`` and ``xs.unwatch`` accept two arguments: a path to watch > and a token. According to the documentation, the second argument must be a > string, which makes sense, since the token should be sent directly to > XenStore. Instead of doing the simple thing (transmitting the token as-is), > the implementation makes a new token from *the pointer* to the token object > and sends it instead: > > PyObject *token; > char token_str[MAX_STRLEN(unsigned long) + 1]; > > snprintf(token_str, sizeof(token_str), "%li", (unsigned long)token); > > This does work for simple cases, e.g. if a token is a string literal > > >>> from xen.lowlevel.xs import xs > >>> h = xs() > >>> h.watch(“@introduceDomain”, “token”) > >>> h.unwatch(“@introduceDomain”, “token”) > > or a small number > > >>> h.watch(“@introduceDomain”, 42) > >>> h.unwatch(“@introduceDomain”, 42) > > But in the general case this is broken > > >>> h.watch("@introduceDomain", 100000000000000000000000000000) > >>> h.unwatch("@introduceDomain", 100000000000000000000000000000) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > xen.lowlevel.xs.Error: (2, 'No such file or directory’) > > Here’s another example with a string token > > >>> token1 = str(100000000000000000000000000000) > >>> token2 = str(100000000000000000000000000000) > >>> token1 == token2 > True > >>> h.watch("@introduceDomain", token1) > >>> h.unwatch("@introduceDomain", token2) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > xen.lowlevel.xs.Error: (2, 'No such file or directory’) > > I’m not sure what would be the best way to handle this as there might be > existing code relying on this undocumented behaviour. What do you think? > In any case this looks like a real bug. The fix (as you said) is to transmit the token. I don't think your proposed fix would break existing users though. Wei. > Regards, > Sergei > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |