Task #2496
closed
Redesign initialization of nfd/nrd
100%
Description
Right now, all initialization of both nfd and nrd is done inside daemon/main.cpp and rib/main.cpp.
In NS-3 and Android environments, it is necessary to manually initialize and start forwarder without use of main function at all (e.g., in both cases there is no command line and there is no config file to parse).
This task is to separate generic initialization of nfd and nrd into separate compilation modules and keep in main.cpp only logic necessary for command line.
Unrelated, but something to consider. getopt uses a global state for argument parsing. This makes main() function non-reentrant. This is not any kind of a problem in normal case, but was something causing problems within android environment.
Should we consider adding "reset" of getopt state, e.g.,
::optind = 1;
::optreset = 1;
Updated by Alex Afanasyev almost 10 years ago
- Related to Task #2489: Merge nrd into nfd added
Updated by Junxiao Shi almost 10 years ago
getopt uses a global state for argument parsing. This makes main() function non-reentrant.
This will conflict if NFD and RIB daemon are in same process but different threads. Use Boost for command line parsing.
Updated by Alex Afanasyev almost 10 years ago
getopt uses a global state for argument parsing. This makes main() function non-reentrant.
This will conflict if NFD and RIB daemon are in same process but different threads. Use Boost for command line parsing.
Not really. We would not need to use separate getopt for nrd when they are combined. The problem I cited happens only in weird cases and we can probably ignore it for now.
Updated by Davide Pesavento almost 10 years ago
If nfd and nrd are merged, I expect command line parsing will be merged as well (i.e. only one call), so the non-reentrancy of getopt() should be a non-issue.
Updated by Alex Afanasyev almost 10 years ago
- Status changed from New to In Progress
- Assignee set to Alex Afanasyev
Updated by Alex Afanasyev almost 10 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
Updated by Alex Afanasyev almost 10 years ago
- Related to Bug #2190: NRD cannot start when NFD disables UNIX faces added
Updated by Alex Afanasyev almost 10 years ago
In nrd, I also made a change related to #2190. Now nrd checks face_system sections and creates a proper transport for the face.
Updated by Alex Afanasyev almost 10 years ago
Just to keep track of discussions. For RIB Management I would like to avoid any global state (= per-management thread global io and scheduler).
Junxiao suggested:
Don't make Scheduler everywhere. Instead, make nfd::scheduler thread-safe by replacing the internal Scheduler with boost::thread_specific_ptr http://www.boost.org/doc/libs/1_48_0/doc/html/thread/thread_local_storage.html
How reliable and safe to use this thing? How to use this in the first place (I never used it)?
Updated by Junxiao Shi almost 10 years ago
How reliable and safe to use this thing?
From Thread Local Storage docs:
It is common practice (and required by POSIX) for compilers that support multi-threaded applications to provide a separate instance of errno for each thread, in order to avoid different threads competing to read or update the value.
boost::thread_specific_ptrprovides a portable mechanism for thread-local storage that works on all compilers supported by Boost.Thread.
This basically says boost::thread_specific_ptr is safe to use with any POSIX compiler.
#2496 doesn't touch the thread-safe issue. RIB daemon should continue to use global nfd::scheduler.
In #2489, a Change before the "merge" should make nfd::scheduler thread-safe by making use of boost::thread_specific_ptr.
How to use this in the first place (I never used it)?
Every developer has a first time using a library feature.
Check Boost tutorial on how to use this.
Updated by Alex Afanasyev almost 10 years ago
- Status changed from Code review to Closed