Web Workers и видимость функций
 

Как в воркере обеспечить видимость глобальных функций, не относящихся к этому воркеру (т. е. созданных в основном потоке)?
P. S. Передача воркеру объекта window генерирует исключение

UPD
Я не сильно надеюсь на ответ, так как сабж еще малоизвестен. Мне нужно каким-то образом подключить библиотеку (http://www.leemon.com/crypto/BigInt.js), но не могу ее просто импортировать в поток, так как там куча глобальных переменных. Пытаюсь аяксом обращаться к js файлу и применить функцию eval, но почему-то это не срабатывает. Уже пробовал

eval('(function(){'+this.responseText+'})()'); //и так
eval('('+this.responseText+')'); //и так

Пока что пытаюсь это сделать в контексте window, но функции не видны. Что я делаю не правильно?

лучше код (каркас) приведите того что вам нужно в итоге....
и наверное стоит обратить внимание на замыкания

monolithed, Workers очень специфичная вещь, передавая объект с набором функций, воркер не видит их. Он их видит, как пустые объекты.
Тут собсно всё просто:

main.js:

var obj = {f: function(){return 'ok';}}
var worker = new Worker('worker.js');
worker.postMessage(obj);

worker.onmessage = function(e){
  console.log(e.data);
};

worker.js:

onmessage = function(e){
  postMessage(e.data.f()); //TypeError: object is not a function
}

Нужно каким-то образом заставить видеть воркер функции, которые я передаю. Нашел костыль, который запускаем в воркере:

importScripts('BigInt.js'); //подобие include

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

функции не обязательно внутрь подключать, их можно через postMessage использовать, как вариант. В случае библиотеки лучше импортировать ее с помощью importScripts, в чем здесь костыль - непонятно

Не получается. Функции передаются как пустой объект.

Конечно, postMessage передаёт только строки.

я не говорю о передаче фукций, я говорю об использовании postMessage как способа вызова функций в другом потоке

Он передает всё, кроме функций.Это уже точно костыль (отталкиваясь от первого поста в теме). Поигравшись немного с "importScripts" уже привык, так что пофиг.

для импорта js-файлов - костыль, но ты же говорил про импорт отдельных функций, так что может пригодится, теоретически...

Я говорю про импорт а не про запуск по команде из postMessage

я тебя не понимаю. Ты хочешь чтобы я не задумывался, в чем заключается твоя проблема, а тупо отвечал на конкретные вопросы? Это не ко мне ;)

Ты сказал, что тебе нужно подключить библиотеку. Специально для этого есть importScripts.

Ты хочешь, чтобы функции передавались? И что, вместе с ней все ее лексическое окружение?

если хочешь дельные советы, приведи какой-нибудь конкретный пример

Привел выше

ты привел абстрактный пример: непонятно, что ты хочешь вынести в отдельный поток и что за функции ты в него хочешь импортировать

Прикалываешься? Мне нужно импортировать в отдельный поток ряд функций, не создавая при этом новый файл.

нет, не прикалываюсь, решение задачи зависит от контекста, а контекст ты не указал

C удивлением обнаружил, что воркеры не работают локально, без веб сервера, значение всех экземпляров воркера — undefined. Может кто знает, как это обойти? Адрес вида "file:///..." не катит.

оно?

x-yuri, да, спасибо. Жаль, что некоторые (или многие) нововведения слегка через жопу сделаны. Не понимаю я, зачем эти ограничения.

не говори "через жопу", пока не понимаешь ;)

Ну вот например, localstorage может хранить только атомарные элементы, хотя спецификация, насколько мне известно, предполагает еще и хранение объектов.

я уверен, что изначально речь шла только о строках, например, потому что в dive into html говорится о строках. Но заметь, что даже сейчас речь не идет о хранении, например, методов обьектов. Или ты считаешь, что методы вместе с DOM-объектами тоже надо хранить?

И не стоит забывать, что спецификация постепенно изменяется. Но тут ничего не поделаешь:

...собственно вот

Просто объектов будет достаточно. Хотя, исходя из моих скромных знаний, я не могу найти причин запрета на хранение DOM элементов и методов.

во-первых, зачем хранить код, если можно обьект из данных воссоздать. Во-вторых, каждый метод привязан к лексическому конексту:

var a = 2, b = 3;
function f(c){ return b + window[c] + document.getElementById('d').value; }

т.е. это что же получается, все текущее состояние окна надо вместе с методом сохранять?

Запретить инкапсуляцию, например?

в смысле? Сохранять методы, игнорируя то, что они привязаны к каким-то переменным? Так оно же работать тогда не будет. В данном случае эффективнее переложить ответственность за преобразование в строку на сам обьект, а не придумывать какое-либо универсальное решение. В случае, например, с eval, который зависит от входных параметров, я не вижу способа отследить используемые переменные. Т.е. при каждом сохранении надо делать полный снимок состояния всех окон, к которым имеется доступ. Но к счастью это не нужно, потому что не сложно написать метод, сериализующий обьект в строку

Ну так поставить такое требование в спецификации, проблем не будет. А инкапсулируемые переменные делать undefined.

Это ладно, с методами вопрос спорный, но вот отсутствие в реализациях хранения объектов — бред.

а как сделать инкапсулируемую переменную undefined? При восстановлении обьекта надо создать глобальную переменную с соответствующим именем и значением undefined? Или исправить код метода?

т.е. то, что реализации соответствуют спецификации, хоть и более старой - это бред? Тогда у тебя наверное есть идеи, как лучше решить эту проблему с браузерами и стандартами. И в конце концов, разве так сложно преобразовать обьект в строку самому?

Просто забивать на переменные, переданные извне (использовать только локальные).
Да, у меня есть идеи: добавление возможности хранения объектов никоим образом не повлияет на приложения, которые уже используют localstorage.Меня смущает одно: вот у меня есть сравнительно крупная база данных (http://www.google.com/fusiontables/D...?dsrcid=850777), её нужно сохранить локально, хватит ли места в строке?

ну так работать же не будет. Причем местами тебе надо будет учитывать, что переменная может быть недоступна. Т.е. вместо того чтобы самому сериализовать обьекты, ты хочешь создать себе ненужные проблемы

ну я говорил про другие проблемы. А с этой проблемой да, ничего не должно поломаться. Но только необходимости в этой большой нету. Есть вопросы по-важнее.

судя по той же ссылке, у тебя есть минимум 5МБ. А БД у тебя небольшая, не вижу проблем

Ну я же буду хранить одну большую JSON строку, вопрос в максимальном размере строки и в максимальном объеме данных, хранимых под одним ключем.

но ты же будешь только данные хранить, а суммарный обьем как минимум 5МБ, ну там написано по ссылке. В конце концов, это самому не сложно выяснить