Сообщение Re[2]: thread safe collection view от 13.12.2022 14:52
Изменено 13.12.2022 14:53 Videoman
Re[2]: thread safe collection view
Здравствуйте, B0FEE664, Вы писали:
BFE>...
По моему это самое хреновое, что можно сделать — лочить всех и вся во время записи, на неопределенное время. Кажется view не так работает. Мы можем взять, условно, слепок контейнера на текущий момент времени и можем модифицировать его как-то, не ограниченно по времени. Потом commit и изменения видят другие. Я конечно не знаю что PVA нужно, приходится гадать.
Как-то приходилось делать такую штуку:
Пишется медиа клип. Данные по размеру сотни гигабайт, короче очень много. Клип может меняться, удаляться и т.д. В любой момент его может открыть неограниченное количество клиентов и они это делают атомарно, т.е. если операция успешна, то клиент получает подобие view, которое от него никуда не денется до закрытия и проигрывать медиа как ему вздумается. Если нужно что-то какое, то нужны дополнительные требования. Например на размер данных, какие операции нужно поддерживать и т.д. Тут все решения будут близки к тому что описал so5team — персистентные иммутабельные хранилища.
Короче в общем виде задача не имеет смысла, из-за требований к памяти, производительности и т.д.
BFE>...
По моему это самое хреновое, что можно сделать — лочить всех и вся во время записи, на неопределенное время. Кажется view не так работает. Мы можем взять, условно, слепок контейнера на текущий момент времени и можем модифицировать его как-то, не ограниченно по времени. Потом commit и изменения видят другие. Я конечно не знаю что PVA нужно, приходится гадать.
Как-то приходилось делать такую штуку:
Пишется медиа клип. Данные по размеру сотни гигабайт, короче очень много. Клип может меняться, удаляться и т.д. В любой момент его может открыть неограниченное количество клиентов и они это делают атомарно, т.е. если операция успешна, то клиент получает подобие view, которое от него никуда не денется до закрытия и проигрывать медиа как ему вздумается. Если нужно что-то какое, то нужны дополнительные требования. Например на размер данных, какие операции нужно поддерживать и т.д. Тут все решения будут близки к тому что описал so5team — персистентные иммутабельные хранилища.
Короче в общем виде задача не имеет смысла, из-за требований к памяти, производительности и т.д.
Re[2]: thread safe collection view
Здравствуйте, B0FEE664, Вы писали:
BFE>...
По моему, это самое хреновое что можно сделать — лочить всех и вся во время записи, на неопределенное время. Кажется view не так работает. Мы можем взять, условно, слепок контейнера на текущий момент времени и можем модифицировать его как-то, не ограниченно по времени. Потом commit и изменения видят другие. Я конечно не знаю что PVA нужно, приходится гадать.
Как-то приходилось делать такую штуку:
Пишется медиа клип. Данные по размеру сотни гигабайт, короче очень много. Клип может меняться, удаляться и т.д. В любой момент его может открыть неограниченное количество клиентов и они это делают атомарно, т.е. если операция успешна, то клиент получает подобие view, которое от него никуда не денется до закрытия и проигрывать медиа как ему вздумается. Если нужно что-то какое, то нужны дополнительные требования. Например на размер данных, какие операции нужно поддерживать и т.д. Тут все решения будут близки к тому что описал so5team — персистентные иммутабельные хранилища.
Короче в общем виде задача не имеет смысла, из-за требований к памяти, производительности и т.д.
BFE>...
По моему, это самое хреновое что можно сделать — лочить всех и вся во время записи, на неопределенное время. Кажется view не так работает. Мы можем взять, условно, слепок контейнера на текущий момент времени и можем модифицировать его как-то, не ограниченно по времени. Потом commit и изменения видят другие. Я конечно не знаю что PVA нужно, приходится гадать.
Как-то приходилось делать такую штуку:
Пишется медиа клип. Данные по размеру сотни гигабайт, короче очень много. Клип может меняться, удаляться и т.д. В любой момент его может открыть неограниченное количество клиентов и они это делают атомарно, т.е. если операция успешна, то клиент получает подобие view, которое от него никуда не денется до закрытия и проигрывать медиа как ему вздумается. Если нужно что-то какое, то нужны дополнительные требования. Например на размер данных, какие операции нужно поддерживать и т.д. Тут все решения будут близки к тому что описал so5team — персистентные иммутабельные хранилища.
Короче в общем виде задача не имеет смысла, из-за требований к памяти, производительности и т.д.