Project

General

Profile

Actions

Task #2496

closed

Redesign initialization of nfd/nrd

Added by Alex Afanasyev about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Build
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

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;

Related issues 2 (0 open2 closed)

Related to NFD - Task #2489: Merge nrd into nfdClosedAlex Afanasyev

Actions
Related to NFD - Bug #2190: NRD cannot start when NFD disables UNIX facesClosed

Actions
Actions #1

Updated by Alex Afanasyev about 9 years ago

Actions #2

Updated by Junxiao Shi about 9 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.

Actions #3

Updated by Alex Afanasyev about 9 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.

Actions #4

Updated by Davide Pesavento about 9 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.

Actions #5

Updated by Alex Afanasyev about 9 years ago

  • Status changed from New to In Progress
  • Assignee set to Alex Afanasyev
Actions #6

Updated by Alex Afanasyev about 9 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 100
Actions #7

Updated by Alex Afanasyev about 9 years ago

  • Related to Bug #2190: NRD cannot start when NFD disables UNIX faces added
Actions #8

Updated by Alex Afanasyev about 9 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.

Actions #9

Updated by Alex Afanasyev about 9 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)?

Actions #10

Updated by Junxiao Shi about 9 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_ptr provides 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.

Actions #11

Updated by Alex Afanasyev about 9 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF