On 7/30/19 7:39 PM, Tamas K Lengyel wrote: > On Tue, Jul 30, 2019 at 9:49 AM George Dunlap <george.dun...@citrix.com> > wrote: >> >> On 7/30/19 2:48 PM, Tamas K Lengyel wrote: >>> On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook >>> <rosbro...@ainfosec.com> wrote: >>>> >>>> Hello, >>>> >>>> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen >>>> summit earlier this month, "Client Virtualization Toolstack in Go", I >>>> would like to open >>>> a discussion around the development of Go bindings for libxl. George >>>> Dunlap, >>>> Nicolas Belouin and I have had some discussion off-line already. >>>> >>>> So far, these are the topics of discussion: >>> >>> Hi Nicholas, >>> to add to the list of topics I just want to mention that perhaps it >>> may be beneficial to consider parts of the go bindings not go to libxl >>> at all. I have been digging through libxl for the past couple months >>> and it's asynchronous callback system is damn near impossible to >>> follow and I just can't shake the feeling that it would be a lot >>> easier to follow if it was in go. >> >> So I don't think we're ever going to switch to golang being our primary >> toolstack language, because calling it from other languages isn't really >> an option. That means that implementing things like domain creation in >> Go mean duplicating functionality in two places, which is >> extraordinarily expensive from a software-engineering perspective. >> >> FWIW I think the asynchronous callback system just needs better >> documentation. It always takes me a little bit to get my bearings again >> once I have to change that code, but once I do, everything is >> consistent. And as I understand it, the external interface was written >> primarily with libvirt in mind, so it would probably be difficult to >> change it while remaining compatible. >> >>> Not to mention the performance >>> issues with the built-in garbage collector >> >> What performance issues were you seeing with libxl's garbage collector? >> I thought it just kept a list of pointers and freed them at the very end. > > I didn't investigate too closely but on some occasions a considerable > amount of the execution time was being spent in there according to > callgrind. After everything was finished in a domain creation xl would > just "hang" in there for a while before actually exiting. It was not > very consistent and recompiling libxl sometimes sped things up. > Haven't run into it since I've upgraded to debian buster and a newer > gcc.
Is it possible this was actually doing the "async" parts of long-running operations? When no async callback is provided, the very last thing that happens before a return is to sleep and wait for the next thing to happen, then call the next thing in the async chain. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
