On Sun, 02.08.09 10:30, Christopher James Halse Rogers (raof at ubuntu.com) wrote:
> On Tue, 2009-07-28 at 16:45 +0200, Lennart Poettering wrote:
> > 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.
>
> So you'd be doing a
> while(state == PA_OPERATION_RUNNING) {
> iterate_mainloop ()
> }
> style loop. I hadn't really considered this. I was expecting a
> callback, but this makes more sense.
Either a loop like that or one with the threaded mainloop, around
pa_threaded_mainloop_wait() (where the callback would just call
pa_threaded_mainloop_signal()).
> > 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.
>
> Right. *This* part is definitely useful; the docs I read didn't make it
> obvious that it'd definitely cancel the callback. I'll try to submit a
> doc patch making this clear.
I have now extended the docs of pa_operation_cancel() a bit to make
this clear.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
