BJ Hargrave wrote: > I think this is just a bad example. The async task even if > wrapped can't mutate the thread locals of the original thread > which seems to be the point of your ContextualService. So even > attempting to push some of that work off to an async task > seems wrong.
What I have in mind for this particular example is actually scenarios where the context is permanently migrated, not shared, to the async thread. So there is no need for writing the contextual info back to the original thread. Examples could include handing over a transaction to be completed in the async thread. For cases where it is desired to share writable contextual data between the two threads, the very same solution may be used but with a level of indirection so the ThreadLocal object points to a shared mutable object. > > In a startup scenario where all > > three bundles have just started, and MyBundle.myMethod() executes, I > > can't be sure that AsyncTaskService has registered my Hook and thus > > started considering the contextual workaround? > > Well your mymethod bundles cannot even know about the hook since > it came from some other bundle. As the hook also is a service from > a bundle, that bundle can be stopped at any time (for updating as > an example). Indeed, my desire is not that MyBundle knows about whether the hook has been registered. But my desire is that ContextualService will not service any bundle that also uses AsyncTaskService until AsyncTaskService has registered its Hook. Thus, in the small time window when AsyncTaskService has just started > > If I want to be sure about this, I guess I need to switch to > > explicit registration with AsyncTaskService (not whiteboard), and > > delay publishing my ContextualService until I know my Hook has been > > registered. Or are there ways to make this work with a whiteboard design? > > Well if the ContextualService requires the hook, how is the hook > an optional thing (the subject line of this thread)? _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
