0

OK, so this may be an odd situation but please bear with me.

I have a Python program which calls up a C++ class via a SWIG interface. I came to a point where I must asynchronously signal (to update a status) the Python code from the C++ library. Originally I had inefficient busy loops which polled a flag. I wanted to replace this by using SIGUSR1.

So, the problem is I discovered that even though these are separate 'threads', they share the same PID. That is the Python and C++ program both report the same PID. I have sent the signal using kill, and the Python code caught it in its handler, however it did not interrupt the code as I expected. I tried two methods of waiting for the signal in the Python code, first py calling Python's signal.pause which I read was supposed to be preempted on the reception of a signal. The other one was a simple time.sleep which was supposed to do basically the same thing - return when the signal comes through.

For some reason this isn't working - my C++ code sends the signal, the Python code receives it and calls the handler, however, the pause/sleep calls never return.

If it is possible to correctly signal the same process, how would you do it?

(and if this is just dumb forgive me and move on)

Mr. Shickadance
  • 5,283
  • 9
  • 45
  • 61
  • NOTE: This is a GNU Radio program, so a main Python thread creates a flow-graph consisting of C++ signal processing blocks. I want to signal the main Python program from one of the C++ blocks. – Mr. Shickadance Aug 04 '11 at 15:57

2 Answers2

2

If you are in the same program I am not sure what you would need signals for in this case. Take a look at the observer pattern. If you have your python event handlers subscribe to events in your C++ library, you can avoid signals all together.

Charles
  • 3,734
  • 3
  • 31
  • 49
2

Signals are not the right tool for the job here. Normally, this would be a job for inter-thread synchronization primitives, such as

  • the locks from the thread module
  • the Event objects from the threading module

However, it's not easy to manipulate Python thread locks from C++. So I would use the old-fashioned, but very simple, approach of

  • a pipe, which the Python thread reads from, and the C++ thread writes exactly one byte to when it wants to wake up the Python.
zwol
  • 135,547
  • 38
  • 252
  • 361
  • Nice idea; a pipe probably is the easiest possible solution, even if using a posix lock of some sort is still a better idea. – SingleNegationElimination Aug 04 '11 at 16:14
  • I like it, but I am not sure about the implementation. Most examples of piping that I've read involve forking a process and connecting one processes stdout to the others' stdin. A Unix filter. In my situation that doesn't seem very applicable since the C++ isn't a separate program. I need to find some examples of Python/C++ IPC using pipes. Thanks! – Mr. Shickadance Aug 04 '11 at 17:49
  • Well, after another minute of thought I think a FIFO (named pipe) is what I need... – Mr. Shickadance Aug 04 '11 at 17:51
  • You can use a regular (anonymous) pipe within a single program. Just read from the read end in the Python thread, and write to the write end in the C++ thread. The easiest way to inform the C++ thread what file descriptor it should write to is: create the pipe before spawning the thread, and then stash the descriptor number in a global variable. (C++ global, that is. Not Python global.) – zwol Aug 04 '11 at 19:21
  • OK, I just got it working. Everything was pretty easy except for one glaring exception. I wasn't aware that opening a pipe for O_RDONLY or O_WRONLY would block until it was opened somewhere else for the opposite (e.g. open for WRONLY blocks until its opened somewhere else for RDONLY). This is documented behavior but apparently I am not the only one to think this changes the expected semantics of `open`. See http://stackoverflow.com/questions/5782279/python-why-does-a-read-only-open-of-a-named-pipe-block – Mr. Shickadance Aug 04 '11 at 19:27
  • Yeah, named pipes are a bit weird. You really shouldn't need them, though. – zwol Aug 04 '11 at 20:31