如何与sock对比？

[yzs15]

您好，我想问一下prewarm_manager = SockPrewarmManager(2, pm, pc) # sock style 是通过这个管理类来对比的吗？还是与https://github.com/open-lambda/open-lambda 这个实现对比的？

[lzjzx1122]

yes, we implement the key design of sock zygote by using SockPrewarmManger.

[yzs15]

A new sock container is created by "fork" system call, which is quite fast, and it is the key idea of the sock. But in your code, the sock container is created by docker "create", which may be unfair. What's more, the sock adopts a tree cache, which is not found in SockPrewarmManger.

[lzjzx1122]

First question, when a function is invoked, it gets a warm container from the prewarm pool. So the docker "create" is only used to generate prewarm containers. We calculate the execution time by "get_prewarmed_container()", and it is only a class passing. I even think it will be much faster than "fork", let alone unfair to Pagurus.

Second, question, As SOCK says, it will create multiple Zygote processes, each importing different packages. These zygotes are maintained as a tree. However, how the zygotes are maintained is not the point we focus, because we already let all containers be able to reuse sock containers from prewarm pool which may "forked" from different zygotes, unless the package conflict occurs. Although it will not affect the performance of SOCK in our evaluation, we still welcome you to submit a pull request to add a tree-based zygote management to improve this part.

I think you should understand that Pagurus focuses on how to quickly install the missing packages (refer to install cache in SOCK) rather than import packages using "fork" (because Pagurus will not import the packages during container init to save memory).

[yzs15]

Thanks for your response. I studied your code and have another question I hope you can answer. In proxy.py, using exec to initialize (or help) still seems to introduce privacy issues (library information can be viewed through sys) and even security issues (because the functions run before are not trusted). I guess the reason for using exec may be to reduce the cost of loading libraries, thereby reducing the cost of cold start.

[lzjzx1122]

Sorry, I do not understand your question. Any function that runs in a forked zygote means this zygote will not be used by others. So how other functions can view lib info in a newly generated Zygote? If you mean the libs from other functions are not removed in the master branch, you can check the safety_patch branch to see how init() removes other libs. The exec() is used to pre-import the libraries and code outside the main() into memory before run(). It helps the container proxy ensure the package importing and global parameters operations outside the main() are only done once during the container lifetime.

[yzs15]

import importlib

#before help
code = compile("import cv2", "mock1.py", mode='exec')
exec(code,{}) #code in init() of proxy.py


#after help
importlib.invalidate_caches()
code = compile("import sys; print(sys.modules['cv2'])", "mock2.py", mode='exec')
exec(code, {})

I followed the logic of proxy.py and wrote an example. The function being helped can directly see the cv2 information.

[lzjzx1122]

Understood. I think you are right and it can have security issues. I think it can be fixed by recording all sys.modules info when the zygote is created, and then let proxy del all newly added modules before help.