你说的对，我已经打算这么干了。把这坨都隔离了。
搞两个process，一个只管读文件，然后pipe给另外一个process去跑业务。

【 在 StephenLee 的大作中提到: 】
: 你这么说，那不是调用第三方函数的问题呀，整个问题都很大。这一坨都别改，全隔离算了。
: 要不是不知道你调用的频率和依赖，都想劝你包装一个独立程序去跑了，调什么api，debug不够烦的。
--
FROM 203.18.50.*

好奇你们的生意一般都在啥地方？

【 在 moudy 的大作中提到: 】
: 标  题: Re: 求助一个glibc相关的问题
: 发信站: 水木社区 (Sat May 13 20:45:58 2023), 站内
:
: 我们给嵌入式系统提供类似于libc这样的基础io库，各种坑见太多了
:
: 【 在 flingfish 的大作中提到: 】
: : 每有读一个文件的时候都这么来一下吗。。
: : 话说你们是用C做什么的，我工作十来年，产品代码里面需要我自己写读写文件功能的不超过3次。。。
:
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 91.39.80.*]
--
FROM 124.207.188.194

好问题，这个坑我也是Google了之后才搞清楚。

  *  The child inherits copies of the parent’s set of open file  descrip-
     tors.   Each  file  descriptor  in the child refers to the same open
     file description (see open(2)) as the corresponding file  descriptor
     in  the parent.  This means that the two descriptors share open file
     status flags, current file offset, and signal-driven I/O  attributes
     (see the description of F_SETOWN and F_SETSIG in fcntl(2)).

具体来说，先open()后fork()的情况下，父子进程不共享用户态的IO buffer，但是共享内核态的文件状态，其中包括offset。

【 在 paramita555 的大作中提到: 】
:
: 大佬，麻烦再解释一下，为啥子进程的exit修改了它自己的offset，我理解父进程中FILE的offset应当不变啊，它又没有重新打开这个文件，为什么还需要手动ftell/fseek呢？
--
FROM 203.18.50.*

O_CLOEXEC并不能解决问题，一方面子进程是fork出来的，不是直接的exec调用；另外一方面，close FILE本身就会导致问题

【 在 paramita555 的大作中提到: 】
: 嗯，确实是父子进程共享文件描述符中的文件偏移，fork和open中都有说明；
: 2.6版本的linux支持O_CLOEXEC标识，应当就可以避免这样的问题了；
--
FROM 114.250.179.*

参考我前面的帖子，close的时候libc的代码会改变file的position
【 在 gameplayer 的大作中提到: 】
: close会导致什么问题？不会互相影响吧？
:
--
FROM 203.18.50.*