On Tue, Feb 09, 2010 at 06:30:47PM +0300, Peter Leonov wrote:

> On 09.02.2010, at 17:26, Igor Sysoev wrote:
>
> > On Tue, Feb 09, 2010 at 05:03:59PM +0300, Peter Leonov wrote:
> >
> >> On 09.02.2010, at 14:06, Igor Sysoev wrote:
> >>
> >>> Я сейчас изучаю v8 на предмет встраивания в nginx
> >> Ура!!! :)
> >>
> >> Тока у v8 есть один неприятный недостаток: он не умеет предупреждать, когда освобождает память под объектом. То есть надежные деструкторы там пока сделать нельзя (есть, правда извороты, но они недокументированные). В принципе, это ничем не грозит, если не будет ситуаций, когда яваскрипт просит энжинкс «попредержать» освобождение запроса.
> >
> > Имеются ввиду weak references ?
> Помню, что обсуждение было возле слабых ссылок (если я правильно понял фразу «weak references»). А потом они (в рассылке) выяснили, что v8 не будет вызывать деструктор (сишный, конечно, в яваскрипте же их нету), перед тем, как удалить объект из памяти. Перл, помнится, умеет вызывать.

Имеется ввиду это обсуждение:
http://groups.google.com/group/v8-users/browse_thread/thread/9effc94911772167/e251b4e048d5a2f2
?

Насколько я понимаю, на этапе шатдауна можно вызвать:

while(V8::IdleNotification());

который будет чистить heap и вызывать callback'и для удаления объектов
с weak references.

> > Что касается недокументированности, то там недокументировано всё, что выходит
> > за пределы банального "hello world!".
> Это да. Но нам не привыкать ;)
>
> >
> >>> и у меня возник вопрос
> >>> по поводу интерфейса - как лучше связать запрос с javascript'ом:
> >>>
> >>> 1) сделать предопределённый объект request, по аналогии с браузерными window
> >>> и document.
> >>> 2) или передавать его первым параметром функции, как в перле и в одной
> >>> из реализаций nginx/v8:
> >>> function handler(request)
> >>> http://code.google.com/p/ngxv8/source/browse/trunk/examples/simple.js
> >>
> >> ИМХО, второй.
> >>
> >> Если использовать первый вариант, то в разные моменты времени глобальная переменная будет указывать на разные запросы. Ее придется выставлять, когда пришел таймер. А иногда она будет вообще пустой или указывать на отработавший запрос. И в любом случае ее придется пересохранять, чтобы запомнить в замыкание. А что будет, если вернутся треды… ;)
> >>
> >> Первый способ легко построить на основе второго практически бесплатно, а вот наоборот будет сложнее (учитывая глобальные и запросовые таймеры, колбеки подзапросов и приема тела).
> >>
> >> А еще глобальные переменные по определению медленнее параметра функции ;)
> >
> > В v8 для каждого запроса, скорее всего, придётся делать свой Context, и
> > в этом контексте будет один экземпляр объекта request. Так что он всегда
> > будет правильный.
> То есть поделиться данными с другим запросом будет нельзя? Да и подтормаживать они должны эти контексты, так как несут полные копии встроенных объектов и всякое такое. А почем вы решили их использовать?

Потому что
http://code.google.com/apis/v8/embed.html#templates

You can create a set of templates and then use the same ones for every new
context you make. You can have as many templates as you require. However
you can only have one instance of any template in any given context.

request - это instance of template. Насколько контексты тяжёлые, пока не
знаю. И также не знаю, можно ли контексты использовать повторно, то есть,
деражть пул использованных контекстов.

> В спайдерманке (он же трейсманки), кстати, контекстам разрешается делиться объектами, если они лежат в одном рантайме.
>
> > А что касается трэдов, то в v8 они только кооперативные.
> Да, и это их архитектурное решение, то есть треды и не предвидятся

One instance of any template in any given context - это тоже архитектурное
решение, потому в Chrome контекст - это окно, которому достаточно
единственного объекта window. Там на самом деле куча архитектурных
ограничений, завязанных на Chrome, начиная с поддерживаемых платформ
и кончая трэдами, контекстами и прочая.


--
Игорь Сысоев
http://sysoev.ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru