On Tue, 28.07.09 15:54, Christopher James Halse Rogers (raof at ubuntu.com) wrote: > I'm (slowly) writing some mono/CLI bindings for pulseaudio, with the > initial goal of writing or enabling a GNOME Do plugin for adjusting the > volume and manipulating streams. Since that touches a wide swathe of > the API anyway, I plan to go on and bind everything. Sounds good! > However, I don't understand what pa_operation is good for. As far as I > can see, you can't wait on a pa_operation, so they're not particularly > useful for completion notification - and every call I've looked at has > some other method of signalling completion anyway. The docs also say > that you can't depend on a cancel call working, so that also seems a > little pointless, and you can't determine success or failure of a call > from a pa_operation. The point of pa_operation is that you can have multiple requests outstanding asynchronously. And of course, you *can* wait for completion with them. Simply let the event loop running until the operation obvject left the PA_OPERATION_RUNNING state. In some cases it makes sense to wait for completion of operations, in others it doesn't. In many situations it hence makes sense to do a loop as suggested above, in others it is fine to _unref the operation right after starting it, because you are not interested in the completion. The callback functions are bound to the pa_operation object. So you can cancel a callback by issuing pa_operation_cancel() and you won't get any callback for it anymore. What the docs say is that the cancel won't necessarily stop the operation itself, but it will still disable the callback. This is very often very important to use since it allows you to make sure to drop all userdata pointers to some specific object when you are destroying it. It really depends on what you are doing if you care or don't care about pa_operation objects. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
