分析 skynet_handle 时感觉 abort 可能会有概率退不出进程

[hanxi]

当新的服务处于创建阶段进行 abort 时，感觉有可能会 abort 失败，却又找不到重现的测试用例，能遇到这样的概率应该极低吧。

1. 线程 A 执行到 ctx->handle = skynet_handle_register(ctx); 产生出 handle 还没赋值时。
2. 线程 B 执行 abort 时跳过了线程 A 的 ctx
3. 线程 A 执行到 context_inc(); 后
4. 其他线程 CHECK_ABORT 是不是就退不出进程呢？

不确定分析是否有问题，也不知道是否有必要像下面的代码加个判断处理这种情况，所以来讨论区问问。

void
skynet_handle_retireall() {
    struct handle_storage *s = H;
    for (;;) {
        int n=0;
        int i;
        for (i=0;i<s->slot_size;i++) {
            rwlock_rlock(&s->lock);
            struct skynet_context * ctx = s->slot[i];
            uint32_t handle = 0;
            if (ctx)
                handle = skynet_context_handle(ctx);
            rwlock_runlock(&s->lock);
            if (handle != 0) {
                if (skynet_handle_retire(handle)) {
                    ++n;
                }
            } else if (ctx) {
                ++n; // 当 ctx->handle = skynet_handle_register(ctx); 已经 ctx 已经进入 slot 但还没返回赋值时
            }
        }
        if (n==0)
            return;
    }
}

[cloudwu]

我觉得只需要在 ctx 不为空时 ++n 就足够了，后面那个 retire 失败的条件都不需要。也就是退出时多循环遍历一次而已。

[cloudwu]

碰到任意一个 ctx 不为空就再循环一次是必须的。因为只有循环下来一个 ctx 都没有，才不会因为有某个服务尝试创建新 handle 而漏过之前已经扫描过的 slots 。之前只在 retire 失败才登记是不够的。

但是这里还遗留一个小问题，如果一个服务自己主动退出，且在退出前创建一个新服务，那么还是有可能在这里遍历在一半的时候，前面增加了一个新 handle ，后面 handle 自己消失。

这个问题暂时不打算解决，在目前的实现下应该不会出现。因为现在创建新服务都是走的 launcher 服务，不会立刻创建。如果要解决，严格来说，此处应该改成写锁，并在 handle_storage 中增加一个退出标记，让这个退出标记阻止新 handle 的创建。