Hi, On Thu, Sep 15, 2016 at 3:43 AM, <r...@ubuntu.com> wrote:
> [...] > > If we *are* going to treat Reports as something that shells can > generically hook into to drive control flow we're going to need to be more > careful about the environment we call them in. For example, currently if a > shell hooks into new_configuration() and requests the base_configuration() > we'll deadlock. I've not worried about ensuring my code doesn't hold any > locks when calling into a Report, nor have I checked that during reviews, > because I've expected the Report implementations to be roughly pure > functions. > Yes - I also see that as one of the core problems here. So we could avoid deadlocks by executing the report implementation asynchronously in a dedicated thread. But I think we want lttng reports to be executed synchronously... we could have two different registration mechanisms to allow both ways of execution. The other problem is that we never intended reports to be useful as observers - so they usually only get the information needed by the default implementations to generate logs/events. So I think instead of what was outlined here in this thread to extend Reports, we should rename DisplayConfigurationReport so that it does not tie with the other Reports. regards Andreas Pokorny
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
