NFD

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.

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.

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.

In nrd, I also made a change related to #2190. Now nrd checks face_system sections and creates a proper transport for the face.

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)?

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.