По классическим работам Хевита(https://en.wikipedia.org/wiki/Carl_Hewitt) акторы не разделяют ничего общего, общение производиться за счет отсылки сообщений.
За счет этого довольно легко запустить огромное количество акторов, а блокирующие нужно выносить отдельно. Файберы же по сути потоки на стеройдах, которые могут иметь общее состояние. Вопрос был об этом.
Олег, спасибо за статью. А правильно понял что основное отличие от акторов реализованных в erlang и Scala — это возможность нормального разделения общих ресурсов?
1. В чем приемущество?
2. тип данных только в тэге? на сколько это быстрее/медленее protobuf?
3. в protobuf есть возможно указать версию самого protobuf 2/3 или расширить схему версией. Тем более если вы расширяете схему, то сервер продолжит работать по старой схеме, то есть обратная совместимость сохраняется
4. в protobuf есть возможность формирования dynamic message — это когда схема на стороне сервера может изменяться. То есть первым сообщением сервер вам отдает динамическую схему. на основании данной схемы вы создаете файловый дескриптор из которого может вытащить дескрипторы полей для декодирования бинарных данных.
За счет этого довольно легко запустить огромное количество акторов, а блокирующие нужно выносить отдельно. Файберы же по сути потоки на стеройдах, которые могут иметь общее состояние. Вопрос был об этом.
Олег, спасибо за статью. А правильно понял что основное отличие от акторов реализованных в erlang и Scala — это возможность нормального разделения общих ресурсов?
а что они сейчас используют? где можно об этом прочесть?
www.erlang.org/doc/reference_manual/typespec.html
выше я описал что это неверно. парсер можно собирать на лету.
Спасибо за ответы.
2. тип данных только в тэге? на сколько это быстрее/медленее protobuf?
3. в protobuf есть возможно указать версию самого protobuf 2/3 или расширить схему версией. Тем более если вы расширяете схему, то сервер продолжит работать по старой схеме, то есть обратная совместимость сохраняется
4. в protobuf есть возможность формирования dynamic message — это когда схема на стороне сервера может изменяться. То есть первым сообщением сервер вам отдает динамическую схему. на основании данной схемы вы создаете файловый дескриптор из которого может вытащить дескрипторы полей для декодирования бинарных данных.