> - There is exactly one Run Loop per thread, which, if used universally, > could present issues because this means behavior would differ from other > Backends.
What do you mean? It can't be necessary to listen to those events in every thread, can it? > A third (and right now, I believe the best) approach would be to add one > or two methods to Pike.Backend that could be implemented by > PollDeviceBackend on Darwin and be used to activate this alternate > mode. I agree. That way it's possible to choose which backend instance to use for those events, as well. I suggest you use function names that make it really obvious that this for platform specific events. E.g: void enable_darwin_events (int(0..1) enable); int(0..1) query_darwin_events(); Then one could add a constant like Pike.BACKEND_GOT_DARWIN_EVENTS, to be able to test compile time whether to compile in calls to those functions (which of course wouldn't exist at all on other platforms). I've got no idea if "darwin_events" is the technically most accurate name, but you get the idea. By using such a clearly platform specific name, it's easier to invent a more generic scheme later if more things like this get added. Then it's another matter if we somehow can make it easier to do the reverse, i.e. to hook in the pike backend in a foreign one. That'd mean a way to query for all the pike fd's, including the wakeup pipe, I guess. Or if it's possible to solve a bit more elegantly when something like kqueue is used.
