LINUX.ORG.RU

[python]Без блокировки: сокеты и UI. Возможно?

 


0

2

Задача - обеспечить параллельную работу программы с сокетами и пользовательским интерфейсом. Т.е. сейчас у меня не получается сделать так, чтобы пользовательский интерфейс не блокировал работу сокетов, с которыми всё нормально. Какие есть варианты для создания UI, не блокируюшего основной цикл программы? Данные из УИ, естественно должны передаваться в основной цикл и наоборот. И ещё - подразумевается не только линуксовая платформа. Пробовал - thread, threading, pyGTK. Возможно в pyGTK есть какая-либо функция которая позволяет «опрашивать события» без вызова gtk.main()?

Есть мысль про subprocess & communicate(), но как-то неудобно. Да и через PIPE-ы передавать данные не шибко весело.

twisted посмотрите, там у них есть дока по интеграции с pygtk

hizel ★★★★★
()
Ответ на: комментарий от anonymous

Плюсую. Glib способен обеспечить неблокирующий ввод/вывод на сокетах.

Olegymous ★★★
()
Ответ на: комментарий от rip86oz

> GIL

Ты хоть выучи, что такое GIL, дуралей. На время блокирующего чтения из сокета он освобождается.

vasilenko ★★
()

Я тебе ещё вчера сказал, НЕ ТРОГАЙ МОЙ ПИСТОНЧЕГ. Тыж идиот.

threading + gobject.idle_add например

anonymous
()
Ответ на: комментарий от rip86oz

Где тот парень на ЛОРе, который кричал что GIL - классная штука и с ним лучше чем без него?

vertexua ★★★★★
()

Попробуй multiprocessing, хотя он и не так удобен.

Какие есть варианты для создания UI, не блокируюшего основной цикл программы?

PyQt с сокетами в QThread-ах

anonymous
()
Ответ на: комментарий от anonymous

Пробовал multiprocessing - блокировка остаётся, хотя странно, ведь «процессинг».

pygtk - да, там есть функция добавления своего стороннего события. Но дело в том, что нужно наоборот - надо проверять наличие событий УИ в основном цикле программы.

Qt - под линуксом конеш +5, но под вендой много гемора.

Скорей всего придётся subprocess + ipc, т.к. реальной многопоточности видимо не добиться.

rip86oz
() автор топика
Ответ на: комментарий от rip86oz

>Пробовал multiprocessing - блокировка остаётся, хотя странно, ведь «процессинг».

У тебя с кодом что-то не то явно. multiprocessing работает на форках, никакого GIL там быть не может. Ты что-то делаешь не так.

Qt - под линуксом конеш +5, но под вендой много гемора.

Отлично работает и там и там. Чем гтк лучше кутей в плане венды - непонятно.

anonymous
()
Ответ на: комментарий от anonymous

Единственно тем, что объёмчег поменьше ) А то минимум кьютовских либ для венды это ~180Мб

anonymous
()
Ответ на: комментарий от rip86oz

Не говори умных слов, значения которых ты не знаешь. Судя по вопрос дятел ты ещё тот.

anonymous
()

ENJOY YOUR AIDSPYTHON

anonymous
()
Ответ на: комментарий от anonymous

>минимум кьютовских либ для венды это ~180Мб
Если говорить о пользовательских dll-ках, то 15-20 отсилы.

GAMer ★★★★★
()

кури мануалы

anonymous
()
Ответ на: комментарий от shty

Ничего. Вокруг достаточно прыщепрограммистов, которые не осилили сменить вариант сборки в криэйторе, но у которых ЧСВ так и требует распростронять свои поделия.

anonymous
()
Ответ на: комментарий от anonymous

Вокруг достаточно прыщепрограммистов, которые не осилили сменить вариант сборки в криэйторе, но у которых ЧСВ так и требует распростронять свои поделия.

какое это отношение имеет к размеру либ под виндой? :)

shty ★★★★★
()

Блээ, какое же здесь сборище идиотов:

threads. (zph)

GIL (rip86oz)


Плюсую. Glib способен обеспечить неблокирующий ввод/вывод на сокетах. (Olegymous)


threading + gobject.idle_add например ()



anonymous
()
Ответ на: комментарий от anonymous

Обоснуй и приведи свой вариант.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.