On successful completion, popen() returns a pointer to an open stream that can be used to read or write to the pipe. Otherwise, it returns a null pointer and may set errno to indicate the error.
따라서 성공인지 아닌지, 리턴값으로 확인한후, 스레드면 좋은 방법은 아니지만, 전역변수를 공유하니까 전역변수를 사용해서 다른 쓰레드에게 이벤트를 전달 할 수 있을것 같네요.
unlink() 또는 remove()로 삭제 시도하고, 리턴값을(에러유무 및 에러라면 원인) 출력해보세요.
추측하건데, 두가지중 하나가 아닌가 합니다.
1) somework()에서 무엇인가? 문제로 인해 쓰레드가 비정상종료했음->따라서, 파일삭제부분이 호출안됨
2) delete()자체가 실패함 -> 퍼미션등의 사유로 실패함
로직이 단순하므로, 2)인지를 먼저 검토해 보시라는 얘기지요.
그렇지 않다면 1)인 경우로 판단됩니다. 사실 rm 명령어 조차도 결국 unlink()로 구현되니까요. popen()으로 rm실행한다고 해결될 문제로 보이지 않는다는 얘기지요.
* 또한, somework()가 시간이 오래걸린다면, 즉, 생산속도가 소비속도를 능가한다면,
처리할 파일 개수(처리후 삭제)에 비해 파일의 생성 수가 과다하다면, 이미 그렇게 하셨듯이, 멀티쓰레드/멀티프로세스로 처리하는 것이 방법입니다. 그러나, 매 파일 마다 쓰레드를 생성하는 것은 바람직하지 않으며, 적절한 수의 쓰레드가 작업을 하게끔 쓰레드풀을 구성하여 수행하도록 하는 것이 안정적인 프로그램으로 가는 방법중 하나 입니다. 이렇게 하는 경우, 피크타임시에 처리할 파일수가 쓰레드수를 능가(?)하는 경우가 있을 수 있는데, 이때, 큐(queue)를 사용하면 좋습니다. 큐의 구현은 파일시스템의 스냅샷으로 해도 좋고(특정 시간에 파일시스템의 파일목록일 읽고 이를 하나씩 처리하도록 쓰레드들에게 분배), 파일명만 어떤 자료구조에 넣어 쓰레드들이 각기 목록을 가져다가 처리하여도 좋겠지요.(당연히 동기화 필요)
만일 파일목록에 의존성이 존재하는 경우,(반드시, 파일1을 처리한 후에, 파일2를 처리해야만한다!) 소위 병렬성이 없는 경우에는 somework()의 성능을 개선하는 방안으로 가야할 것입니다.
cf. 매 파일마다 쓰레드를 만드는 방법이 바람직하지 않은 이유는, 그 프로세스의 비해비어를 예측할 수 없기 때문입니다. 파일이 순간적으로 과도하게 증가하게되면(도스공격?등), 시스템이 마비되는등의 악성 프로그램으로 돌변할 수 있기 때문입니다.
popen manual입니다. On
popen manual입니다.
On successful completion, popen() returns a pointer to an open stream that can be used to read or write to the pipe. Otherwise, it returns a null pointer and may set errno to indicate the error.
따라서 성공인지 아닌지, 리턴값으로 확인한후, 스레드면 좋은 방법은 아니지만, 전역변수를 공유하니까 전역변수를 사용해서 다른 쓰레드에게 이벤트를 전달 할 수 있을것 같네요.
조금 생각을 더 하면 더 좋은 방법도 많이 있을것 같습니다.
thread condition variable을
thread condition variable을 사용하면 쉽게 해결됩니다.
========================================
* 부분이 전체를 대변하는 하나의 속성일때 진리이다.
영속적이지 못한 것은 전체가 될 수 없다.
========================================
* The truth will set you free.
스레드간 실행되는게 아닌데도 되는건가요?
제가 만든것의 구조는 다음과 같습니다.
main()
{
pthread_creat(&tid,,&doit,);
}
doit
{
somework, make file ( filename.ts)
delete (filename.ts)
somework2, make file ( filename2.ts)
delete (filename.ts)
somework3, make file ( filename3.ts)
delete (filename.ts)
}
이런식입니다.
파일을 상당히 많이 만드는데요..
문제는 delete를 하는것이 그냥 지나쳐버리는 경우가 있는것 입니다.
그리고, somework가 무언가를 분석하는 것인데
시간이 많이 걸려서
스레드가 여러개 생기고 어쩌고 하면,
특히 그러는것 같은데요..
그래서..
delete(rm -f "somefile.ts")를 하는데
이 실행이 정상적으로 되었는지를 확인한 다음에 다음으로 넘어가고 싶어서입니다.
popen으로 해서
while(fget()){
}
으로 해도 마찬가지 현상이 있었습니다.
---
cond로 이게 되는건가요 ㅠㅠ
Fly to the SKY~~~~~~
"According to your faith, be it unto you!!"
Fly to the SKY~~~~~~
"According to your faith, be it unto you!!"
unlink() 또는 remove()로
unlink() 또는 remove()로 삭제 시도하고, 리턴값을(에러유무 및 에러라면 원인) 출력해보세요.
추측하건데, 두가지중 하나가 아닌가 합니다.
1) somework()에서 무엇인가? 문제로 인해 쓰레드가 비정상종료했음->따라서, 파일삭제부분이 호출안됨
2) delete()자체가 실패함 -> 퍼미션등의 사유로 실패함
로직이 단순하므로, 2)인지를 먼저 검토해 보시라는 얘기지요.
그렇지 않다면 1)인 경우로 판단됩니다. 사실 rm 명령어 조차도 결국 unlink()로 구현되니까요. popen()으로 rm실행한다고 해결될 문제로 보이지 않는다는 얘기지요.
* 또한, somework()가 시간이 오래걸린다면, 즉, 생산속도가 소비속도를 능가한다면,
처리할 파일 개수(처리후 삭제)에 비해 파일의 생성 수가 과다하다면, 이미 그렇게 하셨듯이, 멀티쓰레드/멀티프로세스로 처리하는 것이 방법입니다. 그러나, 매 파일 마다 쓰레드를 생성하는 것은 바람직하지 않으며, 적절한 수의 쓰레드가 작업을 하게끔 쓰레드풀을 구성하여 수행하도록 하는 것이 안정적인 프로그램으로 가는 방법중 하나 입니다. 이렇게 하는 경우, 피크타임시에 처리할 파일수가 쓰레드수를 능가(?)하는 경우가 있을 수 있는데, 이때, 큐(queue)를 사용하면 좋습니다. 큐의 구현은 파일시스템의 스냅샷으로 해도 좋고(특정 시간에 파일시스템의 파일목록일 읽고 이를 하나씩 처리하도록 쓰레드들에게 분배), 파일명만 어떤 자료구조에 넣어 쓰레드들이 각기 목록을 가져다가 처리하여도 좋겠지요.(당연히 동기화 필요)
만일 파일목록에 의존성이 존재하는 경우,(반드시, 파일1을 처리한 후에, 파일2를 처리해야만한다!) 소위 병렬성이 없는 경우에는 somework()의 성능을 개선하는 방안으로 가야할 것입니다.
cf. 매 파일마다 쓰레드를 만드는 방법이 바람직하지 않은 이유는, 그 프로세스의 비해비어를 예측할 수 없기 때문입니다. 파일이 순간적으로 과도하게 증가하게되면(도스공격?등), 시스템이 마비되는등의 악성 프로그램으로 돌변할 수 있기 때문입니다.
조언 감사드립니다.
감사합니다 ^_^
Fly to the SKY~~~~~~
"According to your faith, be it unto you!!"
Fly to the SKY~~~~~~
"According to your faith, be it unto you!!"
댓글 달기