Здравствуйте! Спасибо за Ваши замечания, указанный фрагмент кода из статьи действительно содержит опечатку - block обязательно должен быть вызван внутри блока perform на фоновом контексте, вместе с safe и rollback.
Реализация варианта с child/parent контекстами выглядела именно так как Вы написали, соответствующие правки будут внесены в статью!
Касаемо Вашего утверждения:
Если бы Вы сделали правильно, то проблем бы не возникло:
Это не совсем так. В этом разделе статьи указано, почему этот метод было решено не использовать:
Однако контекст все еще тащит информацию через readContext и как следствие через main очередь, поэтому child/parent подход в моем случае не подошел.
В своем ответе я буду основываться на книге от objc.io по Core Data (глава «Complexity of Nested Contexts»), тредах stack overflow, такие как этот, а также на результах профилирования работы приложения.
При сохранении child контекста, информация переносится из child в parent контекст, во время этого процесса блокируются как child, так и parent контексты. Так как в нашем случае parent контекст имеет тип .mainQueueConcurrencyType, эта операция блокирует основной поток и может заметно влиять на отзывчивость UI. Это подтверждается как при реальном использовании приложения, так и профилированием.
CoreData потоконебезопасна.
Это заблуждение. Методы выше, как раз и сделаны для того, чтобы кордатой пользоваться потокобезопасно.
Соглашусь, что определение потокобезопасности может трактоваться по-разному, и обобщать весь фреймворк этим термином не совсем корректно, это тоже будет отражено в статье!
Но, в то же время, ссылаясь на документацию Apple, CoreData действительно проектировалась с учетом многопоточного программирования, но для этого нужно соблюдать правила работы с инструментами, предоставляемыми фреймворком. Так как во фреймворке существуют инструменты для решения проблемы потоконебезопасности, можно сделать вывод, что определенные компоненты потоконебезопасны по умолчанию.
Хочу добавить, что я не претендую на истину и приветствую любую дискуссию, ведь так и выявляется правда! Спасибо!
Здравствуйте! Спасибо за Ваши замечания, указанный фрагмент кода из статьи действительно содержит опечатку - block обязательно должен быть вызван внутри блока perform на фоновом контексте, вместе с safe и rollback.
Реализация варианта с child/parent контекстами выглядела именно так как Вы написали, соответствующие правки будут внесены в статью!
Касаемо Вашего утверждения:
Это не совсем так. В этом разделе статьи указано, почему этот метод было решено не использовать:
В своем ответе я буду основываться на книге от objc.io по Core Data (глава «Complexity of Nested Contexts»), тредах stack overflow, такие как этот, а также на результах профилирования работы приложения.
При сохранении child контекста, информация переносится из child в parent контекст, во время этого процесса блокируются как child, так и parent контексты. Так как в нашем случае parent контекст имеет тип
.mainQueueConcurrencyType, эта операция блокирует основной поток и может заметно влиять на отзывчивость UI. Это подтверждается как при реальном использовании приложения, так и профилированием.Соглашусь, что определение потокобезопасности может трактоваться по-разному, и обобщать весь фреймворк этим термином не совсем корректно, это тоже будет отражено в статье!
Но, в то же время, ссылаясь на документацию Apple, CoreData действительно проектировалась с учетом многопоточного программирования, но для этого нужно соблюдать правила работы с инструментами, предоставляемыми фреймворком. Так как во фреймворке существуют инструменты для решения проблемы потоконебезопасности, можно сделать вывод, что определенные компоненты потоконебезопасны по умолчанию.
Хочу добавить, что я не претендую на истину и приветствую любую дискуссию, ведь так и выявляется правда! Спасибо!
Спасибо за комментарий, вот ссылочка на репозиторий :)
https://github.com/lolsmh/SwiftUILayoutProtocolTest