0

I want to exit the parallel process from one of the defs (using a return?), so that the program continues after the last line of this code:

from threading import Thread

def measureBT():
    try:
        ...
        return True
    except TimeoutException:
        ...
        return False

def measureWiFi():
    ...


thread_MeasureBT = Thread(target=measureBT)
thread_MeasureWiFi = Thread(target=measureWiFi)

thread_MeasureBT.start()
thread_MeasureWiFi.start()

thread_MeasureWiFi.join()
thread_MeasureBT.join()
fairly99
  • 25
  • 8
  • when you say interrupt, do you mean like abort or kill? i.e. do you want to kill a thread before it has completed? From the code you wrote, with thread_MeasureWiFi.join() the main waits for thread_MeasureWiFi to finish before proceeding to the next command, which is to wait for thread_MeasureBT. After that, the main will move to whatever is written after. why do you think that this code does not exit from the parallel process? – Wippo Dec 04 '20 at 09:42
  • the code exits the process, already checked it. I just want it to exit the thread MeasureWiFi and, ideally, to also exit the other thread (MeasureBT) at the same time, so that the program continues with the next code – fairly99 Dec 04 '20 at 09:55
  • the only way you can make two threads exit at the same time is to kill the slowest one as soon as the fastest one has finished its execution. This means that you will kill the slower one and you can never assume that it has executed a certain amount of code before it dies. If you want both functions to execute completely before you move to the next operation, the code you've written already does – Wippo Dec 04 '20 at 10:06
  • I found this about [Terminate multiple threads when any thread completes a task](https://stackoverflow.com/questions/6286235/terminate-multiple-threads-when-any-thread-completes-a-task) – Wippo Dec 04 '20 at 10:07
  • 1
    actually, as an alternative, you could use a variable shared by the two threads and run a check to determine within one thread if the other thread has already finished. in this way they don't end at exactly the same time, because you'll still have to wait for one of them to modify the variable and for the other to check it – Wippo Dec 04 '20 at 10:12
  • Thats the option I am trying right now, seems the most elegant. – fairly99 Dec 04 '20 at 10:19
  • Sorry, @Wippo - the concept of a "shared"-lock is prone to self-live-lock, when all -3- peers ( main, BT, WiFi ) wait for a somewhere lost soft-lock signal. Not a good design practice to infinitely lock the main, is it? – user3666197 Dec 04 '20 at 10:41
  • @user3666197 surely it is. This is the reason why as first suggestion i said "when the fastest one has finished, kill the slower one" as also suggested in the post i linked after that message. In any case, the shared lock is indeed an alternative which allows you to ensure that some code has been executed by the thread before exit, even if it is prone to errors. I should have stressed more why it came to my mind only as last option, which is the reason you just pointed out in the comment. – Wippo Dec 04 '20 at 10:57
  • Referring to **threads** as **processes** is likely to confuse - they are very, very different things. – Mark Setchell Dec 04 '20 at 11:27

1 Answers1

0

Q : "I want to exit the parallel process from one of the def-s..., so that the program continues after the last line of this code:"

The idea is clear, the approach is awfully wrong.

If this were used in NASA Apollo Programme for going to the Moon, there would be a first non-terrestrial grave in the Mare Tranquillitatis.

Never try to depend on a process / thread termination / completion like was assumed above.

Better create a structure of cooperating-agents, one (or more, for a more fault-tolerant system) responsible for any and all independent BT-measurements, another (again independent on any other agent, resource or processing) a one for all the WiFi-measurements.

This way, if something gets wrong (and it often does, most often in the worst moment, like during the Moon-landing, when Radar started to spray the central AGC-computer with error-signalling and if it were not for the smart & brave work from Ms. Margaret Hamilton, who re-designed the principles of how to control the complex system right into the set of independently controllable, non-blocking, the less mutually {dead-|live-|panic-attack-}-locking entities, the mission would have turned into a world-wide watched Lunar funeral ).

So, best split the concerns, one for the BR, another one for the WiFi and keep the main process communicate with them, be it using the O/S-based or nanomsg/pynng or ZeroMQ / pyzmq communication frameworks, that help you create a robust, non-blocking meta-plane(s) for such a system, using either of or all of TransportClass(es) available for local ipc:// or even non-local tcp:// inter-agent communications.

There you will have all the recent readings available in due time & fashion ( independently of how the remote-agents get them ), having even the chance to resolve any such case as an error-readout or missing-data, if your design gets closer to the principles demonstrated by Ms. Margaret Hamilton for NASA, some half century ago already.

Ultimate respect to all those MIT-Team Human Heroes and the lectures on the Art-of-(dependable)-Code-Design

halfer
  • 19,824
  • 17
  • 99
  • 186
user3666197
  • 1
  • 6
  • 50
  • 92