popen-locks 또는 thread safe하지 않습니까?

popen()/pclose()에 대한 몇 가지 구현을 보았습니다.popen-locks 또는 thread safe하지 않습니까?

static int *pids; 
static int fds; 

if (!pids) { 
     if ((fds = getdtablesize()) <= 0) 
      return (NULL); 
     if ((pids = malloc(fds * sizeof(int))) == NULL) 
      return (NULL); 
     memset(pids, 0, fds * sizeof(int)); 
    }

또는이, 가정 NetBSD의 : - A는 안전 구현을 스레드하지 그것이 어떻게 생겼는지

static struct pid { 
    struct pid *next; 
    FILE *fp; 
    pid_t pid; 
} *pidlist; 

    /* Link into list of file descriptors. */ 
    cur->fp = iop; 
    cur->pid = pid; 
    cur->next = pidlist; 
    pidlist = cur;

가 그들 모두의 PID의 정적 목록없이 잠금을 사용? 또는 나는 명백한 것을 놓치고 있는가?

출처

2009-11-09 n-alexander

GNU libc implementation은 libc가 재진입 성 (가능할 수 있음)으로 구성된 경우 threadsafe입니다. 그러나 libc의 다른 구현에서는 그렇지 않을 수 있습니다.

출처

2009-11-09 17:43:29 bdonlan

예, 어린이 목록을 잠급니다. 이것은 훨씬 낫다. 링크를 가져 주셔서 감사합니다. 필자는 pid를 리턴 한 popen을 원했고 pclose로 전달했지만,이 경우 libc 옵션이 아닙니다. –

나는 당신이 뭔가 분명한 것을 놓치고 있다고 생각하지 않습니다. thread-safe에 대한 참조가 popen()에서 thread-safe인지 여부를 알지 못합니다. 결과적으로 스레드가 안전하지 않은 것으로 간주해야합니다.

출처

2009-11-09 17:35:43 Aaron

스레드가 지원 될 때, 함수가 안전하거나 안전하지 않은 경우 명시 적으로 알려주는 맨 페이지가 기억납니다. 이제는 함수가 다르게 말하지 않는 것이 안전 할 것으로 기대합니다. –

그것은 좋을 것입니다. 그러나 - 나는 당신의 기대를 뒤집을 것이다 - 저자가 스레드 문제에 대해 실제로 생각하지 않는 한 일반적으로 안전하지 못하다. 맨 페이지에 언급되지 않았다면 아마 그것에 대해 생각하지 않았을 것입니다. – Aaron

적어도 Linux에서는 맨 페이지가 반드시 구현을 작성한 glibc에 의해 작성된 것은 아닙니다. – bdonlan

popen-locks 또는 thread safe하지 않습니까?

답변

관련 문제