0

I'm controlling a process P over a user interface which ideally acts as a daemon and gets launched by the user interface. P depends on a server handshake, so always needs some time to initialize. A very, very basic implementation of this process (without interface, simple execution) would look like (Python mixed with some pseudocode):

from Library import handshake, verySlowFunction, listenForNewIds
import time

address = 'some connection string'   
localInformation = 'some local information' 
print("Connecting to server.")
token = handshake(address)
runner = verySlowFunction(token)

while True:
    """ Your turn, guys... """
    if launch_new
        try:
            runner.exec(idFromInterface)
        except SIGKILL:
            break

    listenForNewIds()
    time.sleep(0.1)

The function verySlowFunction.runner() needs around 3 minutes and blocks the whole thread. Unfortunately, for some specific reason that I can hardly influence, both verySlowFunction() and handshake() need to be executed in the same thread. So this has to be launched as a subprocess or similar

What I want is some possibility to

  • wait for external signals
  • not to kill the whole process altogether (I could simply launch the process over and over, but don't want to do the handshake every time, since I theoretically only need it once)

I should mention that "Library" is a *.so library that was written in Rust, so simply killing it with SIGINT doesn't work. I haven't found a nice way to kill the function and not kill the whole process with it.

I have read about the asyncio package in Python 3.5 (which I'm using) and together with signal, that "feels" like a solution to this. I simply don't know how to get it work.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
freistil90
  • 113
  • 2
  • 8
  • There is nothing specifically in Rust that should prevent you from terminating the child process with a signal. Is there something you tried on this end that did not work? – E_net4 May 12 '17 at 13:57
  • Very well possible, I don't know if a C library would behave differently than a Rust library. I have tried all kinds of things to at least suppress the output of `handshake()` but that didn't work. The thing is, of course I can kill the whole process and just reopen it, but it would be great if I could just "interupt" the execution of `runner()` **alone** and keep the rest intact. So far, SIGINT wouldn't kill the function, only SIGTERM. And that kill the whole process, I'm not sure how to route the signal into the daemon process and kill the `try` part only. – freistil90 May 12 '17 at 14:03
  • To answer that part, it certainly depends on how the implemented functions behave, which you did not show or describe. The question still misses many details: what does `verySlowFunction` provide? Does it yield a subprocess descriptor? Also note that you should not be able to catch KILL signals applied to the same process. – E_net4 May 12 '17 at 14:23
  • Maybe I should be a little bit more explicit, I was hoping for a more general answer. I'm talking about a modified example of `play.py`from python-librespot ( [link](https://github.com/plietar/python-librespot) ), maybe you can take a look. Since Library is librespot.so in this case and I really don't know if this rust function yields a subprocess descriptor, feel free to look. I'm trying to build a daemon process out of play in a way that it listens for track-ids and plays them until a stop signal comes. the player blocks everything, so pause etc are a little useless... – freistil90 May 12 '17 at 14:45
  • I'm sorry, but asking for a general answer here will likely make the question too broad and unclear. I have been suggesting improvements in your question to avoid this. For starters, you should specifically discover what those functions do and what they return. Second, consider learning more about system signal handling, in order to understand that signals are not captured the same way as Python exceptions. See also [How do I capture SIGINT in Python?](http://stackoverflow.com/questions/1112343/how-do-i-capture-sigint-in-python). – E_net4 May 12 '17 at 15:03
  • I actually figured it out! The function was calling a Future object which apparently launches a thread, which I naturally can't cancel that easy. Thanks anyways! – freistil90 May 12 '17 at 15:38

0 Answers0