multithreading - IronPython: StartThread creates 'DummyThreads' that don't get cleaned up -

the problem have in ironpython application threads being created never cleaned up, when method run has exited. in application start threads in 2 ways: a) using python-style threads (sub-classes of threading.thread in run() method), , b) using .net 'threadstart' approach. python-style threads behave expected, , after 'run()' exits cleaned up. .net style threads never cleaned up, after have exited. can call del, abort, whatever want, , has no effect on them.

the following ironpython script demonstrates issue:

import system import threading import time import logging  def do_beeps():     logging.debug("starting do_beeps")     t_start = time.clock()     while time.clock() - t_start < 10:         system.console.beep()         system.threading.thread.currentthread.join(1000)     logging.debug("exiting do_beeps")  class pythonstylethread(threading.thread):      def __init__(self, thread_name="pythonstylethread"):         super(pythonstylethread, self).__init__(name=thread_name)      def run(self):         do_beeps()  class threadstarter():      def start(self):         t = system.threading.thread(system.threading.threadstart(do_beeps))         t.isbackground = true         t.name = "threadstartstylethread"         t.start()  if __name__ == '__main__':      logging.basicconfig(format='%(asctime)s %(levelname)s: %(message)s', level=logging.debug, datefmt='%h:%m:%s')      # start threadstarter threads:     _ in range(5):         ts = threadstarter()         ts.start()         system.threading.thread.currentthread.join(200)      # start python-style threads:     _ in range(5):         pt = pythonstylethread()         pt.start()         system.threading.thread.currentthread.join(200)      # on main thread:     _ in range(30):         print(".")         system.threading.thread.currentthread.join(1000) 

when debugged in pydev, see threads appear expected in 'debug' view created:

but whereas python-style ones disappear after they've finished, .net / threadstart ones stay until main thread exits.

as can seen in image, in debugger problematic threads appear names 'dummy-4', 'dummy-5' etc, whereas pythonic ones appear name i've given them ('pythonstylethread'). looking in threading.py file in ironpython installation see there class called "_dummythread", subclass of thread, sets 'name' 'name=_newname("dummy-%d")', looks using threadstart i'm ending _dummythreads. comment class says:

# dummy thread class represent threads not started here. # these aren't garbage collected when die, nor can waited for. 

which explain why can't rid of them.

but don't want 'dummythread's. want normal ones, behave nicely , garbage-collected when they've finished doing thing.

now, odd thing of unless set logger don't see dummythread entries in debugger @ (although still run). may funny of pydev debugger, or may relevant. there sane reason why logging should have bearing on this? can solve problem not logging in thread?

here, says:

"there possibility "dummy thread objects" created. these thread objects corresponding "alien threads", threads of control started outside threading module, such directly c code. dummy thread objects have limited functionality; considered alive , daemonic, , cannot joined. never deleted, since impossible detect termination of alien threads."

which makes me wonder why i've had misfortune of ending them?

while have workaround in can use python-style threading.thread subclasses everywhere use .net 'threadstart' threads, not keen reason using .net style threads in places because give me abort method (whereas python ones don't). know aborting threads bad thing, application unit-testing framework, , a) need run unit-tests in thread, , b) have no control on contents (they written third-parties), have no means of periodically checking 'please shut me down nicely' flag on these threads, , in extremis may need kill them rudely.

so a) why getting dummythreads, b) has got logging , c) can it?

thanks.