如何使用 Go 实现一个 OJ 的评测机？

我有一个方法。。。上 github 借鉴借鉴。。。

uoj 的做法好像是 docker

做的第一个项目就是和同学一起搞了个 oj，评测机直接拉一个 docker 起来跑完删掉。。。我记得这个方案的缺陷是无法区分内存爆掉和超时的情况？

@zxCoder 代码完全读不懂

@SunspotsInys 那也得硬读。。。我想应该不会有资料一步一步教怎么做一个评测机

去搜搜本科论文库，有不少 CS 的哥们本科毕业设计做的这个

以前的一个面试官写的，并且用在他们学校的校赛上了，你可以参考一下，整体不难，一个调度中心，一堆 worker https://github.com/ma6174/acmjudger

如果想了解一下简单的判题原理的话可以看看我的博客文章 https://www.lanrongqi.com/2020/08/online-judge-development-2 ，这个是我自己用的 go 写的判题机 https://github.com/LanceLRQ/deer-executor ， 不过没有实现沙箱功能，生产环境是直接放 docker 里跑的。也没用到 cgroup 那些，在学了在学了...(￣￣)
顺便给你个我虽然没用过但是看源代码感觉还蛮厉害的 go 语言判题机 https://github.com/criyle/go-judge
一起学习交流呀

考虑下用 Docker 吧，如果有人乱搞得考虑 OJ 被黑掉的场合

@casparchen #3 +1

单纯的 docker 不一定安全，gvisor 应该更靠谱些。
印象还有超轻虚拟机+docker 方案。

@LanceLRQ 就是这个源码我看不懂，配上作者的博客也无法理解

非主流方法：如果评测机用的是 Ubuntu 等自带 AppArmor 的系统的话，倒是可以不用容器，通过 AppArmor 来实现安全加固。

内存和时间限制，一般来说是联用轮询和 rlimit 系统资源限制：
1 ）定时器限制时间+轮询采样内存消耗情况作为主要监控手段，用于反馈 TLE/MLE
2 ） rlimit 系统限制设得比题面描述高一些，用来保底
（不单用 rlimit 是因为超限程序会被直接杀死，从而无法区分 RE, TLE 和 MLE ；而且无法限制程序的非用户态时间）

另外，安全方面还有 ptrace, seccomp 等传统方法。

@qbqbqbqb 嗯，我再试试