0

I implemented a while loop with locks in python-2.7 (see example) to handle two lists which are loaded with values by an other thread each. The code works, but it will not handle SIGINT (Ctrl-C) anymore. Example:

while True:
  with lock1:
    if 0 < len(data_buf1):
      foo(data_buf1.pop(0))
  with lock2:
    if 0 < len(data_buf2):
      bar(data_buf2.pop(0)

What could I do to enable keyboard commands again?

Update The loop runs in the main python process.

Torus Gently
  • 1
  • 1
  • 1
    signals and threads do not mix well. It's possible that only the main thread will receive the signals... See [here](https://docs.python.org/3.5/library/signal.html#signals-and-threads), quote: *Python signal handlers are always executed in the main Python thread, even if the signal was received in another thread. This means that signals can’t be used as a means of inter-thread communication. You can use the synchronization primitives from the threading module instead.* – Bakuriu Jun 29 '16 at 11:50
  • Thank you, I forget to mention that my loop is in the main process. – Torus Gently Jun 29 '16 at 12:03
  • What are the types of `lock1` and `lock2`? – Aya Jun 29 '16 at 12:04
  • allocate_lock from the module thread – Torus Gently Jun 29 '16 at 12:11
  • Do we need locks at all? Updating mutable data from distinct threads is not the whole reason for why we have the GIL? – Paulo Scardine Jun 29 '16 at 12:11
  • Your code works for me. I can still CTRL-C out of `lock = thread.allocate_lock(); with lock: while 1: pass`, so it may be another issue. – Aya Jun 29 '16 at 12:16
  • Thx, I will check it. The other threads are ROS callbacks. I relized a minute ago, that they stop working after pressing CTRL-C. So, signals come trough and the problem is somewhere else. – Torus Gently Jun 29 '16 at 12:29
  • @PauloScardine No. The GIL only prevents the threads to switch between *bytecodes*. It is used to make so that things like reference counts and GC can be implemented easily. – Bakuriu Jun 29 '16 at 13:22

0 Answers0