On Mon, Aug 04, 2008 at 12:20:56PM -0700, Roland McGrath wrote: ... > The callback synchronization thing is simpler when we have an engine > pointer that can be relied on, even when you block. I'm guessing > everyone will be happy to see reference counts replace RCU in the > interface for dealing with struct utrace_attached_engine.
Yes! > So here is what I'm thinking: > > utrace_attach returns a ref for the caller. You can use > utrace_engine_get(engine) and utrace_engine_put(engine) to manage the > pointer. When you drop the last ref, the struct is freed. There are no > release/destructor callbacks for that, the refcount is purely for the > purpose of keeping the pointer valid. What is the use case for a utrace client to do a utrace_engine_get/put()? Wouldn't it be more robust if utrace implicitly handles refcounts as you've detailed below? > An implicit ref is held while the engine is attached. The engine > pointer can always be used during a callback because of this ref. Your > callback can add a new ref even if you had dropped all other refs. If a > callback returns UTRACE_DETACH, then this ref will be dropped (and might > be the last). Will this also take care of the utrace engine vs. task_struct lifetime issues that Alexey reported in http://www.redhat.com/archives/utrace-devel/2007-August/msg00002.html and http://www.redhat.com/archives/utrace-devel/2008-January/msg00019.html ? Ananth
