小编Jac*_*per的帖子

用于slice::from_raw_parts警告程序员使用正确的生命周期注释切片的文档.我假设,考虑到一些生命周期'a,我可以执行此注释

let myslice: &'a mut [i32] = std::slice::from_raw_parts_mut(ptr, sz)

我也认为

• 由于myslice是引用,它与ptr指向的底层数据的分配/释放无关.生命周期注释不会影响数据的内存管理.
• 关于myslice自身的内存管理(即包含指针和大小的结构)并没有什么棘手的问题.它就像任何其他结构或i32.如果我把它放在一个Box,那么std::raw::slice结构将在Box死时被释放.当然,切片引用的数据不会被解除分配.生命周期不会影响切片的内存管理.

为什么让生命保持正确至关重要？在设定切片寿命时,使用后是免费的唯一危险吗？

我正在寻找一个类似于Vec<RefCell<T>>它的类,因为它是所有数据的最终所有者和分配器,但是阵列的不同部分可以被多方无限期地可变地借用.

我无限期地强调,因为当然Vec<T>也可以由多方共同借用,但这样做涉及进行分割,只有在各方借款后才能解决.

Vec<RefCell<T>>似乎是一个充满危险的世界和许多丑陋的if陈述检查borrow_state,这似乎是不稳定的.如果你做错了什么,那么kablammo!恐慌!这不是借阅图书馆的样子.在借阅图书馆,如果你要求一本不存在的书,他们会告诉你"哦,它已经签出了." 爆炸中没有人死亡.

所以我想编写这样的代码:

let mut a = LendingLibrary::new();
a.push(Foo{x:10});
a.push(Foo{x:11});
let b1 = a.get(0); // <-- b1 is an Option<RefMut<Foo>>
let b2 = a.get(1); // <-- b2 is an Option<RefMut<Foo>>

// the 0th element has already been borrowed, so...
let b3 = a.get(0); // <-- b3 is Option::None 

这样的事情存在吗？或者是否有另一种规范方式来获得这种行为？一种"友好的RefCell"？

如果答案是肯定的,那么还有一个线程安全的变体吗？

我假设多处理程序包使用pickle在进程之间发送消息。但是，泡菜要注意对象的__getstate__和__setstate__方法。多处理似乎忽略了它们。它是否正确？我感到困惑吗？

要复制，请安装docker，然后在命令行中键入

$ docker run python:3.4 python -c "import pickle
import multiprocessing
import os

class Tricky:
    def __init__(self,x):
        self.data=x

    def __setstate__(self,d):
        self.data=10

    def __getstate__(self):
        return {}

def report(ar,q):
    print('running report in pid %d, hailing from %d'%(os.getpid(),os.getppid()))
    q.put(ar.data)

print('module loaded in pid %d, hailing from pid %d'%(os.getpid(),os.getppid()))
if __name__ == '__main__':
    print('hello from pid %d'%os.getpid())
    ar = Tricky(5)
    q = multiprocessing.Queue()
    p = multiprocessing.Process(target=report, args=(ar, q))
    p.start()
    p.join()
    print(q.get())
    print(pickle.loads(pickle.dumps(ar)).data)"

你应该得到类似

module loaded in pid 1, hailing …