Quoth andrew rutz on Mon, Jun 18, 2007 at 05:04:20PM -0500:
> i'm also seeing another race when i add a "sleep(10)" in syseventd's
> child-proc code (right before it enters its FOREVER) loop.
>
> i've got system/sysevent as system/picl's Dependency, but w/ this
> SLEEP in the Child code, the Parent sysevent code is exiting and
> seemingly satisfying smf's requirements... but this seems to be
> the type of bug you've referred to: syseventd is announcing that
> it's ready to provide a Service... yet its child-proc hasn't
> completed (and set a global that's returned by i_ddi_io_initialized()
> ...and used for inter-process synchronization).
Right.
> ps - 'seems like a cool tool would be a static-analysis tool (like
> warlock) that would check the src code for violations of Dependencies
> (that are computable statically). eg, in my case, any code calling
> i_ddi_io_initialized() would have to AT LEAST have system/sysevent
> as its Dependency (as syseventd sets the global that that func
> returns). (eg, system/picl was erroneously dependent on
> milestone:/filesys/minimal... even though cscope shows that picld calls
> i_ddi_io_initialized(); it was only a matter of time/cases before
> failure would occur).
>
> all Dependencies could not be computed at compile-time, but it would
> find the easy cases... 'whether in new code or modified code.
I agree. See
6469371 Dependency ferret
David
