nerijus
Андрей Светлов
А в вашем случае события - это что?
Наверное речь идет о threading.Event, поскольку было упомянуто set(). События используется когда один поток ждет сообщения от другого. Я не думаю что автор блокирует GUI поток и ждет изменения _isRunning… Это было бы нелепо. Я никогда не работал с tkinter (скорее всего на нем пишется), но думаю тут как и везде нужно передавать не event, a сигнал (в случае Qt, или message в случае win32 api). И статус (_isRunning), как параметр. А обработчик этого сигнала в GUI потоке уже пусть делает что хочет. Все это будет thread safe без всяких событий и блокировок. Только нужно знать как этот сигнал передавать чтобы он в GUI потоке обрабатывался. В разных виджетах по разному называется - postmessage, callafter и т.д. просто нужно посмотреть документацию. Канечно можно и не в GUI потоке обрабатывать, если нет нужды что либо отображать.
Да, именно о threading.Event. GUI сделал GTK. По поводу того как сделано поясню немного. FooWindow и proxy в разных потоках
class FooWindow(object):
def reload(self):
self.proxy = localproxy('127.0.0.1', 8080)
self.proxy.start()
self.status()
def status(self):
print self.proxy.isRunning
isRunning устанавливается в True в методе start() прокси. Но при вызове status() оно ещё False. Сейчас я по сути протаскиваю объект “события” в объект прокси, там его при старте (сразу после выставления переменной isRunning) выставляю методом set(), и код преобритает вид примерно такого:
class FooWindow(object):
def reload(self):
e = threading.Event()
self.proxy = localproxy('127.0.0.1', 8080, e)
self.proxy.start()
e.wait()
self.status()
def status(self):
print self.proxy.isRunning
Оно работает, но меня волнуют архитектурные проблемы :)