Tilman Sauerbeck wrote: >>> This just doesn't apply to the argument to the service method. What we >>> get there isn't a common result, but some strange bastard ;) >>> It makes no sense at all to call xmmsc_result_notifier_set on it, for >>> example, or xmmsc_result_wait, or xmmsc_result_get_value. >> Isn't that true for all results passed to callbacks that it makes no sense >> to call xmmsc_result_notifier_set and xmmsc_result_wait in the callbacks? > > Oh man, I didn't see that %) > Yes, you are right. If you're looking at the service method notifier > function as a result callback then it all adds up.
This is interesting. The "problem" is that result is both refers to the pending pending call, and its returnvalue. Maybe we should split the _value_ to a xmmsc_value_t (or whatever) that just is a pretty container for the different datatypes we have. The notifiers would change the signature to: void notifier(xmmsc_value_t *, void *usedata); Or maybe not void.. Maybe signals should be able to return things like "WANT_RESTART" And the thing referring to the pending call would just be the cid (= an int). This would probably fit pretty nicely with genipc.. anders -- _______________________________________________ Xmms2-devel mailing list Xmms2-devel@lists.xmms.se http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
