Александр Кошелев
Март 31, 2011 14:27:34
o7412369815963
Да, кэп, это все и так прекрасно знают.
Речь как раз о том и есть, что контекст веб-запроса не должен быть глобальным стейтом. Это признак и причина плохой архитектуры.
Андрей Светлов
Март 31, 2011 14:51:07
Пять копеек. Зачем Веркцойг имеет свою реализацию thread local? Потому, что в stackless эти потоки не равны системным. Приходится ходить конем. А как быть в случае twisted или tornado? Повод еще раз подумать…
o7412369815963
Апрель 1, 2011 23:41:23
Александр Кошелев
связанные с ним проблемы (например, отсутствия разделения кода на зависящий от текущего контекста (реквеста) и независящий) их мало напрягают.
“отсутствия разделения кода”, почему это проблема? наоборот - преимущество. хочешь разделяй, хочешь не разделяй - разработчик сам проектирует приложение.
какие ещё проблемы имеет глобальный контекст?
Андрей Светлов
А как быть в случае twisted или tornado?
а что с twisted и tornado? без глобального контекста - их право, это не значит что он плох.
Андрей Светлов
Апрель 2, 2011 08:01:07
Я имею в виду, что запустить Flask под twisted не запихивая обработку запросов в threadpool - невозможно. werkzeurg.local этого не умеет, хотя для stackless отнорочек есть.
ZZZ
Апрель 2, 2011 09:05:45
Андрей Светлов
запустить Flask под twisted
Вы, всё-таки, редкостный извращенец… Зачем такое может понадобиться, в мою плохо проснувшуюся голову не влезает.
Андрей Светлов
Апрель 2, 2011 09:39:40
Хорошо. WSGI — это контейнер.
Последний год я вижу вялотекущие разговоры о том, что было бы здорово подружить WSGI с неблокирующими сокетами.
Реализовав их, например, в том же nginx - он ведь от рождения неблокирующий? Да только с thread local variables это не выйдет.
o7412369815963
Апрель 2, 2011 17:01:44
Андрей Светлов
Хорошо. WSGI — это контейнер.
Последний год я вижу вялотекущие разговоры о том, что было бы здорово подружить WSGI с неблокирующими сокетами.
Реализовав их, например, в том же nginx - он ведь от рождения неблокирующий? Да только с thread local variables это не выйдет.
Когда реализуют, тогда появятся соответствующие фреймворки, а пока thread local - это удобно.
В фреймворке bottle, thread local используется только для того что-б дать ссылку на environ (грубо говоря). Во входной ф-ии (передача управления от wsgi) в thread local ссылка обновляется на текущий environ, так что данный фремворк с thread local может работать в неблокирующем режиме.
Андрей Светлов
Апрель 2, 2011 18:06:20
Насколько я вижу, используются bottle.request и bottle.response. Что же это, как не thread local?
o7412369815963
Апрель 2, 2011 22:51:57
Андрей Светлов
Насколько я вижу, используются bottle.request и bottle.response. Что же это, как не thread local?
в реализации requset все параметры сохраняются в том самом environ который прилетает от wsgi
def __getitem__(self, key): return self.environ[key]
def __delitem__(self, key): self[key] = ""; del(self.environ[key])
def __iter__(self): return iter(self.environ)
def __len__(self): return len(self.environ)
def keys(self): return self.environ.keys()
Андрей Светлов
Апрель 2, 2011 23:13:47
Еще раз смотрю на исходники из
https://github.com/defnull/bottle.git Версия свежая, только что обновился.
bottle.Request и bottle.Response унаследованы от threading.local
bottle.request и bottle.response - экземпляры этих классов.
Что же это, как не крепкая привязка к thread local? Каким образом в одном потоке может работать несколько wsgi application одновременно?