Indeed, both are useful and can be implemented independently.

The system/library APIs I'm calling into are all async so I suppose that approach is the easiest. However, that places the burden on the Pike application to wait long enough (maybe a second or two) to find services.

Another thing is unclear to me: the library functions take a void *context value and I'd stuff the browser object in there. But how can I be sure the context pointer I get handed in the callback is the same object I had initially (or even a valid object)? In this case I believe I'm able to cancel an ongoing lookup task from the object's exit callback so I'm probably safe anyway.

I thought of that too, but will the object ever be destructed then? I want the lookup task to be running for the lifetime of the browser object, but since I'm holding the last reference myself it seems it will remain valid forever. In other words, instead of performing the cleanup in the object's exit callback I need a notification when the refcount reaches 1, right?

Too bad the callback isn't single-shot... This is how I envision the Pike API to work:

{ object b = Browse("_http._tcp"); res1 = b->get_results(); // get all results so far res2 = b->get_results(); // get all results so far b->stop(); // terminate async lookup res3 = b->get_results(); // all results at the time of stop() }

Now, if I don't call stop() the results array should keep updating for as long as b is valid. Handling destruct(b) should be easy, but the problem is if b goes out of scope and loses a ref; since we've added a ref internally we won't detect that case and the lookup will continue forever.

I'm thinking I'm better off not adding the ref to begin with. Then my destroy() method can do whatever stop() does to cancel the lookup, and I'll pray that the callback isn't invoked with an old object any more (which shouldn't happen unless there are bugs in the library).