当对全局文件描述符调用 fclose 时,程序挂起。
它发生在由克隆创建的几个线程退出后。
下面是顺序:
FILE * fid = fopen("filename", "w");
...
for(int i=0; i<4; i++){
clone((int (*)(void*))do_work, stack[i], CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|SIGCHLD|CLONE_CHILD_CLEARTID|CLONE_PARENT_SETTID|CLONE_IO, NULL, &(ctid[i]), NULL, &(ctid[i]) );
}
...
fclose(fid);
非线程处理fid。
从 strace 来看,程序卡在 futex 中等待“main_arena”。我认为这应该是 glibc 内部的一些互斥体。
回溯:
#0 0x0000003f09edf9ee in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x0000003f09e76d31 in _L_lock_5478 () from /lib64/libc.so.6
#2 0x0000003f09e71c8d in _int_free () from /lib64/libc.so.6
#3 0x0000003f09e7273b in free () from /lib64/libc.so.6
#4 0x0000003f09e60d5b in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
这种情况发生在使用 glibc 2.5 的 Linux 上,但不会发生在使用 glibc 2.12 的 Linux 上。
我想知道是否是因为我们无法像这样使用clone()创建线程。在NPTL中,还做了很多事情,比如set_robust_futex()和设置线程本地存储。
谢谢!
我无法想象您会期望它如何工作。 stdio 库在内部使用锁。锁特定于所使用的线程模型。您正在使用自己的线程模型,但期望 stdio 库的锁能够神奇地与其一起工作。这显然不是一个合理的期望。
我是一名优秀的程序员,十分优秀!