> On Oct. 6, 2014, 11:56 p.m., Benjamin Hindman wrote: > > src/examples/example_module_impl.cpp, line 32 > > <https://reviews.apache.org/r/25848/diff/14/?file=713786#file713786line32> > > > > To Bernd's point above, if you declare/define this at the bottom then > > you won't need the forward declarations up top. I like this pattern, define > > everything you need before the Module<T> declaration/definition, which will > > tend to come at the bottom of files! > > > > A bigger concern I have, however, is regarding the lifetime of these > > objects. What happens if/when the dynamic library gets closed? Or what > > about when the application gets shutdown? Are these subject to > > destructors/cleanup? If so, either we need to have module writers create > > Module<T>* or we need to do deep copies when we read the symbols the first > > time (which actually still won't be immune to potential destruction because > > an application might be shutting down right when we start to read the > > symbol which could cause a crash, probably not the worst thing since the > > application was already being shutdown but still not a great user > > experience).
After giving it some more thought, I realized that neither the deep copy, nor putting the object on heap help us with improper interleaving during application shutdown. In both cases, the create() and compatible() methods will still be part of the dynamic library and if it is dlclose()'d, then the application is going to crash if someone tries to call create() or compatible. - Kapil ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25848/#review55568 ----------------------------------------------------------- On Oct. 7, 2014, 6:43 p.m., Kapil Arya wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/25848/ > ----------------------------------------------------------- > > (Updated Oct. 7, 2014, 6:43 p.m.) > > > Review request for mesos, Benjamin Hindman, Bernd Mathiske, Niklas Nielsen, > and Timothy St. Clair. > > > Bugs: MESOS-1384 > https://issues.apache.org/jira/browse/MESOS-1384 > > > Repository: mesos-git > > > Description > ------- > > Adding a first class primitive, abstraction and process for dynamic library > writing and loading can make it easier to extend inner workings of Mesos. > Making it possible to have dynamic loadable resource allocators, isolators, > containerizes, authenticators and much more. > > > Diffs > ----- > > include/mesos/module.hpp PRE-CREATION > src/Makefile.am c62a974dcc80f3c3dd6060aee51f8367a0abe724 > src/common/parse.hpp e6153d8a1f25bc9ddbe1e391306beeacfc8d5ff6 > src/examples/example_module_impl.cpp PRE-CREATION > src/examples/test_module.hpp PRE-CREATION > src/messages/messages.proto 9ff06b38086010df362036c695a5222371f70f4d > src/module/manager.hpp PRE-CREATION > src/module/manager.cpp PRE-CREATION > src/tests/master_tests.cpp 705e5f2c0f9d693946e722cef63f38f3bff0d46b > src/tests/module_tests.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/25848/diff/ > > > Testing > ------- > > Ran make check with added tests for verifying library/module loading and > simple version check. > > > Thanks, > > Kapil Arya > >
