Реализация автосохранения без нарушения

Question

Я взломал код для Xournal, чтобы добавить функцию автоматического сохранения. Моя первоначальная реализация была очень тупой: каждые 60 или около того секунд, сохраняйте. Функция якобы работает.

Однако, после проверки на какое-то время, я заметил, что при автоматическом сохранении приложение временно замерзает, что довольно неприятно, если вы находитесь в середине хода пера. Я пытаюсь понять, как это исправить.

Одна из возможностей, которую я придумал, - это автосохранение, чтобы проверить, не касается ли пером экрана перед автосохранением; если он коснулся, приложите один раз только обратный вызов, запланированный на секунду после поднятия пера. (если происходит то же самое, повторите). Другой возможностью было бы оптимизировать функцию сохранения достаточно, чтобы не было пробела (кажется маловероятным).

У кого-нибудь есть предложения по этому вопросу? Xournal использует инструментарий Gnome/GTK, и написан на C.

Update: Я реализовал логику анти-затирать, и я очень доволен результатом автосохранения детализации и производительности. Одна из тех времен нитей (к счастью) не нужна! Спасибо всем за ваши предложения.

Answer 1

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

Если вы в конечном итоге используете потоки, используйте g_threads вместо pthreads, так как вы используете GTK +. Они будут более портативными.

Answer 2

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

У меня очень мало опыта с c, но я думаю, что this site может помочь.

Answer 3

Хотя я бы согласился использовать потоки, это «правильный» ответ текстового поля, это не всегда так, как вам нужно делать. Многопоточность имеет тенденцию вызывать массу проблем, если вы не будете осторожны - главная из них, вероятно, заключается в блокировании доступа к данным во время автосохранения. Затем, если основной поток заходит на ожидание доступа к данным, вы вернетесь туда, где вы начали. Итак, вы создаете очередь ожидающих изменений или чего-то еще, и вы теряете информацию о том, что происходит. В зависимости от того, насколько сложны базовые структуры данных, создание копии также может заморозить основной поток.

Anyways пункт есть, я бы попробовал ваш первый вариант. Это быстро, просто и точно, и я не понимаю, почему это не сработает.

(Примечание:.. Я не смотрел под капотом Xournal так возьмите это с зерном соли или соли шейкер или что-то)

Answer 4

я имел подобную ситуацию в прошлом, и вот как я ее решил (.Net):

1. таймер фона клещей при х секундными интервалами
2. на клеща, отключить таймер и обрабатывать соответствующее событие.
3. В обработчике событий сохраните и включите таймер.

Единственный недостаток, который мы видели на самом деле, заключался в том, что кто-то убил приложение до того, как обработчик события вызван и потерял 1 минуту работы.

Answer 5

Как насчет этого?

Используйте идею обратного вызова, но запустите каждые 10 входов каждые 60 секунд. При использовании автосохранения, основанного на времени, существует проблема, заключающаяся в том, что количество потерянного материала пропорционально скорости работы пользователя.

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

Answer 6

Основное внимание уделяется использованию потока hipervisor, сравнивающего через некоторый алгоритм хэширования содержимое файла каждый N секунд на событии изменения, а затем уведомляет о родительском потоке и вызывает функцию автосохранения.