Bug 375

Created attachment 342 [details]
rough patch

I had a first patch.  The naive approach:

        while (!ns3::Simulator::IsFinished())
        {        
            if (PyEval_ThreadsInitialized())
                py_thread_state = PyEval_SaveThread();
            ns3::Simulator::RunOneEvent();
            if (py_thread_state)
                PyEval_RestoreThread(py_thread_state);
            PyErr_CheckSignals();
            if (PyErr_Occurred())
                return NULL;
        }

Problems:

 1- I had to patch ns3::Simulator::IsFinished() to consider also the m_stop variable of the scheduler, otherwise my custom loop will ignore the Simulator::Stop() call;

 2- Obviously there is an overhead of checking for signals on _every_ simulator iteration.  On my system, the measured overhead (in the csma-bridge.py example) is 3.5% if the threading python module is not imported, or 4.3% with threading imported (there's an optimization that avoids the Python GIL calls if threading is not being used).

I then modified the patch a bit.  The attached patch takes a parameter 'signal_check_frequency', which is the number of iterations to run before checking for signals, or -1 to not check for signals at all.  With the default value of 100, the overhead is only 0.7% for non-threaded programs, which I think is acceptable.  Ctrl-C is, of course, very responsive.

A better approach would be, perhaps, to create a thread which asks python to check for interrupts every second or so, and sets a global flag when interrupt is detected, so that the simulation loop can check for that variable, which should have less overhead.  But I think this patch is much less complicated and has reasonably low overhead, so I'll settle for it, if no objections.

I have to ask, what to do with the Simulator::IsFinished change?  Is it OK to commit, or propose a new API call to do what I want, or...?

Committed a cleaned up patch.