Enchantner
Сен. 10, 2009 07:02:04
Для начала убедись, что это правда баг, а не фича :)
o7412369815963
Сен. 10, 2009 10:40:36
slav0nic
ахтунг, 2300 не исправленных багов… похоже мой баг уже в списке
PooH
Сен. 10, 2009 12:16:05
o7412369815963
slav0nic
ахтунг, 2300 не исправленных багов…
Ничего не ахтунг, вы обратили внимание - не меньше половины это feature request
slav0nic
Сен. 10, 2009 12:38:06
o7412369815963, тем не мение, я на баги лишь пару раз натыкался
Lolka
Сен. 10, 2009 20:23:58
o7412369815963, а покажите, а? Хочу видеть настоящий питон-баг :)
o7412369815963
Сен. 11, 2009 05:44:04
NSkrypnik
+1
Баг в студию!
я уже о нем писал, вот
http://python.su/forum/viewtopic.php?pid=32468#p32468так нигде ответа ещё и не нашел
точно такой же баг есть в классе BaseHTTPRequestHandler
poltergeist
Сен. 12, 2009 13:08:52
Это всё-таки не баг, а фича. Причём не питона, а вообще. Попробую описать что происходит:
Если не запускать дочерний процесс, то соединение как надо разрывается и клиент благополучно выходит из цикла приёма данных получив свой законный “len(buf) == 0”, означающий разрыв соединения. При создании дочернего процесса ресурсы родительского процесса (все дескрипторы в юниксах, кроме 0, 1, 2, и все хэндлеры в винде) наследуются в дочернем процессе, поэтому сокет и не закрывается, пока дочерний процесс не умрёт или не освободит занятый ресурс. Чтобы всё работало как задумывалось, надо в subprocess.Popen передать дополнительный параметр close_fds=True.