2

I'm stuck at a tricky problem to test whether a daemon thread is running. The daemon thread I made should run at the background to keep the service running, so I do the following to create it and keep it alive:

Creation:

ASThread = threading.Thread(target = initAirserv, args=[],)
ASThread.setDaemon(True)
ASThread.start()

Inside the initAirserv() method:

def initAirserv(self, channel="15"):
        interface = self.execAirmon(options="start", interface=self.interface)
        port = self.plug_port
        if interface != "removed":
            if channel=="15":
                command = "airserv-ng -d " +str(interface)+" -p "+str(port)
            else:
                command = "airserv-ng -d " +str(interface)+" -p "+str(port)+" -c"+str(channel)
        else:
            return None
        AServConn=self.init_Plug()
        if AServConn:
            (stdin, stdout, stderr) = AServConn.exec_command(command)
            serv_op = stdout
            serv_er = stderr
            ##### keep the daemon thread run persistently ####
            a = 0 
            while 1:
                a += 1
        else:
            logging.debug( "SSH Error" )

The purpose of the last several lines is to keep the thread busy using a stupid way. However, after starting this daemon thread and I did something else, when I came back and check the thread as follows:

if ASThread.is_alive() == 1:
    # do something

the if body never gets executed. Can someone explain to me why does this happen? What's the best way to run a thread which executes something that needs to be busy all the time? Thanks very much.

Shang Wang
  • 24,909
  • 20
  • 73
  • 94

2 Answers2

2

The posted code doesn't add up. initAirserv as posted is a method on a class, but the initAirserv passed to the Thread constructor is not.

It's also hard to say anything concrete without knowing what execAirmon and init_Plug does, and what else happens in your application.

In general, I'd say you have it right. This should work. The fact that it doesn't means your assumptions are wrong.

  • Are you sure execAirmon returns something that is not equal to "removed"?
  • Are you sure init_Plug returns a non-false object?
  • Are you sure no exceptions are thrown? (I assume you would notice a spurious stacktrace, so are there other parts of your application that could swallow them up unnoticed?)
Epcylon
  • 4,674
  • 2
  • 26
  • 35
0

Some of my information is a few months old, and things may have changed, so please bear with me.

If you are using standard C based Python and are writing a multi-threaded application, you need to be aware of the Global Interpreter Lock (GIL) restriction. That is only one thread can run at a time. If you are willing to use one of the Python C interface packages and write a lot of your code in C, the C portion of your function call can be threaded and is not subject to the GIL restriction.

Python has excellent multi-process support and libraries, and because you are synchronizing processes, the GIL restriction does not apply.

There is talk about fixing the GIL restriction, but for now this is a problem you have to accept.

IMHO, I chose Python to write software in Python, not in C, unless a very specific problem had to be addressed. Python is an excellent language for a lot of things, but the GIL restriction encouraged me to learn a language that would support better event synchronization, aka a multi-threaded environment.

I hope this helps.

octopusgrabbus
  • 10,555
  • 15
  • 68
  • 131
  • Thanks for your information. Are you suggesting that since GIL applies to multiple threads for the same process, I should not do it in my way? – Shang Wang Mar 21 '12 at 18:16
  • I am by no means a Python expert. I am only suggesting only that you do some digging into the GIL restriction. The GIL restriction was discussed in The Boston Python Meetup within the last year, so things may have changed since then. I have not looked into it any further. I still use Python for a lot of things, because it is a good language and has a lot of support. – octopusgrabbus Mar 21 '12 at 18:36
  • The GIL has no relation to the OPs question as far as I can tell. The GIL only really comes into play when you have multiple processors, where it would prevent the interpreter from using more than a single processor at a time. All threads would still run to completion, they would just be scheduled by the interpreter to run interleaved (like threads always do on a single processor). – Epcylon Mar 21 '12 at 21:18
  • I answered based on my own knowledge and answers within stackoverflow itself, like http://stackoverflow.com/questions/7404904/python-global-interpreter-lock-gil-problem . My answer was basically, use processes instead of threads. – octopusgrabbus Mar 22 '12 at 14:40