gpt4 book ai didi

ios - 是否递归调用 performBlockAndWait : allowed?

转载 作者:行者123 更新时间:2023-11-29 01:55:22 24 4
gpt4 key购买 nike

上下文:使用 Core Data,我在私有(private)队列上有一个主上下文(我将调用 mainContext),在主队列上有另一个上下文,主队列的子队列(我将调用子上下文)。队列无关紧要,我的问题的答案不应取决于上下文所在的队列。

我的目标是将 childContext 的修改直接保存到磁盘,而不让 mainContext 有机会在 childContext< 带来的修改之前进行任何修改 被保存到磁盘。

为了做到这一点,我调用:

[self.childContext performBlockAndWait:^{
[self.parentContext performBlockAndWait:^{
[self.childContext save:NULL];
[self.parentContext save:NULL];
}];
}];

背后的想法是,如果我执行一个 block 并同时等待子上下文和父上下文,则在保存子上下文时不能对主上下文进行任何修改。然后主上下文被保存,我们退出 block 。该文档明确指出对 performBlockAndSave: 的调用是可重入的,因此这应该有效。

是吗?对 performBlockAndWait: 的嵌套调用是否有效?显然,保存都是在 mainContext 的队列上完成的,并且 childContext 的队列在保存期间没有被锁定。正常吗?如果是这样,我怎样才能实现我的目标?


注意:由于我与 API 通信的方式,我需要这种原子性。为了在我的 API 上创建一个对象,我在本地创建对象,然后检查 Core Data 上下文中的本地修改,并将这些修改转换为 API 调用。如果我打电话:

[self.childContext performBlockAndWait:^{
[self.childContext save:NULL];
/* 1 */
[self.parentContext performBlockAndWait:^{
[self.parentContext save:NULL];
}];
}];

有可能在 performBlockAndWait: 保存 mainContext 之前调用 mainContext 上的 performBlock: (在 1)。此调用将有一个“不干净”的上下文,childContext 中的更改等待保存在磁盘上。

最佳答案

我认为解决方案是在上下文层次结构的下方创建更多的子上下文。

为了清楚起见,请允许我重新命名您的上下文:

我们将 mainContext 称为 rootContext(后台,保存到持久存储)。
我们将 childContext 称为 mainContext(主线程上下文,rootContext 的子级)。
让我们将任何较低的子上下文称为“工作上下文”(背景,mainContext 的子上下文)。

worker 上下文应该是以主上下文为父上下文的背景上下文。

你可以有一个中心位置,根上下文将保存到物理商店,例如你在哪里管理你的核心数据堆栈。

据我了解,当通过 save: 将更改从 worker 上下文推送到主上下文时,同时主上下文本身也在 performBlockAndWait block ,它只会在完成后获取更改。只有这样它才能将它们进一步推到根上下文以进行物理保存。我认为这应该可以实现您的原子性目标。

通过引入工作上下文,您可以确保根上下文不会从主上下文以外的任何其他地方接收任何更新。

关于ios - 是否递归调用 performBlockAndWait : allowed?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30926746/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com