On Fri, Jan 25, 2008 at 03:07:39PM -0800, Liane Praza wrote: > David Bustos wrote: > >Quoth Nicolas Williams on Fri, Jan 25, 2008 at 04:30:32PM -0600: > >>I gave a specific example, but I think that a non-polling way to learn > >>about SMF service state changes is important. I think that because in > >>general non-polling interfaces by which to discover various system state > >>changes are useful. > > > >I agree. Please file an RFE. > > The version of this for administrators, who may want something > higher-level than a C API is filed as: > > 6577813 SMF should natively support actions (snmp trap, script, > email) on service transition
I don't think that's the same thing, unless there be an action that is light-weight (compared to doing forkx()/exec()) for local consumers. And even then! Why should subscription to SMF events require setting a property of each service of interest? A simple API would allow the caller to build a list of FMRIs and FMRI patterns whose state transitions the caller is interested in. A way to watch other administrative actions (get/set prop) might be useful as well. But the API has to be scallable -- no polling, no per-service or per-pg door/remote calls. Asynchronous APIs please too... Thinking ahead to a future when we might have a remote SMF protocol, one should not have to burn a thread per-remote system being watched. The world of per-client/server threads is (and should be) dead -- it doesn't scale. Nico --
