The backtrace below shows a situation where trying to exec tap-creator
in src/devices/tap-bridge/tap-bridge.cc leads to deadlock when trying
to acquire the python GIL.  This might be due to trying to access
python objects after fork() without calling PyOS_AfterFork() to
properly reset python state (including the GIL).


#0  0x00ca1422 in __kernel_vsyscall ()
#1  0x00b8ef75 in sem_wait@@GLIBC_2.1 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x081047a8 in PyThread_acquire_lock ()
#3  0x080d74fc in PyEval_RestoreThread ()
#4  0x080f83c8 in PyGILState_Ensure ()
#5  0x0100ac75 in PyNs3Node__PythonHelper::GetInstanceTypeId (this=0x9c05bc8)
    at debug/bindings/python/ns3_module_node.cc:38580
#6  0x01aa4847 in ns3::Object::DoGetObject (this=0x9c05bc8, tid=...)
    at ../src/core/object.cc:142
#7  0x01d52a2d in ns3::Object::GetObject<ns3::Ipv4> (this=0x9c05bc8)
    at debug/ns3/object.h:394
#8  0x01ebb4d5 in ns3::TapBridge::CreateTap (this=0x9bf5638)
    at ../src/devices/tap-bridge/tap-bridge.cc:373
#9  0x01eba163 in ns3::TapBridge::StartTapDevice (this=0x9bf5638)
    at ../src/devices/tap-bridge/tap-bridge.cc:220


The included patch is a workaround that moves GetObject() to before
the fork().  Creating a new ns3::fork() function would probably be a
better way to handle things more transparently.

There is also a fork() in src/devices/emu/emu-net-device.cc, but
without any python interaction before calling exec().