• 카테고리

    질문 & 답변
  • 세부 분야

    프로그래밍 언어

  • 해결 여부

    미해결

wait의 done(), not_done() 그리고 as_completed의 cancelled 질문입니다!

21.01.01 13:28 작성 조회수 183

0

안녕하세요! 우선 새해 복 많이 받으세요! 다름이 아니라 as_completed의 cancelled 메소드에 대해서 몇 가지 궁금한게 있습니다! 

1. wait 같은 경우에는 설정한 timeout을 초과하는 작업에 대해서는 not_done()으로 출력해줄 수 있고 취소된 작업이 뭔지 확인할 수 있습니다!

그렇다면 as_completed는 애초에 구현되는 과정이 WORK_LST의 work들을 submit해서 append해준 futures_lst 리스트안에 담긴 작업들을 다시 for문으로 돌려서 작업들 중 시간이 적게 걸리는 작업들을 자동적으로 파악해서 알아서 시간이 적게 걸리는 작업들 순으로 동시성을 수행해주는 건가요? 

2. 1번에서 설명드렸던과 같이 어쨋든 as_completed는 작업이 적게 걸리는 순으로 작업을 해준다고 한 것이고 결과적으로 작업이 엄청나게 많은 시간이 걸려도 어쨋든 '모든 작업을 완료' 한다는 점에서 wait와는 다르다고 판단됩니다(wait는 timeout 설정을 해주니깐요!) 그렇다면 as_completed에서 cancelled 메소드는 어떤 이유로 존재하는 건가요? cancelled 메소드가 취소된 작업이 무엇인지 알려주기 위한 것인데, 시간이 아무리 오래 걸리는 작업도 '수행 완료' 상태는 되기 마련인데, 그렇다면 모든 작업들에 대해 cancelled는 False일 거고... cancelled 메소드의 존재 이유가 궁금합니다!

3. 마지막으로 wait의 done(), not_done()에 대한 질문인데요! 다음과 같이 done()된 작업들, not_done()된 작업들 결과물로 이렇게 표시가 되는데, <Future at ~~~ > 이런식으로 나오는 표기를 보고 수행된 또는 중지된 작업들이 구체적으로 '내가 만든 어떤 작업'인지 어떻게 알 수 있나요..? 메모리 id(0x7fa~~같은 값들)를 보고 알아차려야 하나요?

답변 2

·

답변을 작성해보세요.

0

아하 as_completed 메소드에서도 timeout 파라미터가 있었군요! 밖이신 데도 답변 감사드립니다!

0

네! 복많이 받으세요 영훈님!

밖이 짧게 답변드리겠습니다.

1. 맞습니다.

2. 항상 작업이 완료된다는 보장이 없습니다. 예를들어 서버측 요청에 무기한으로 대기가 걸릴수도 있고

    기타 다른 변수들이 많기 때문에 canceld 메소드가 존재합니다.

concurrent.futures.as_completed(fstimeout=None)

Returns an iterator over the Future instances (possibly created by different Executor instances) given by fs that yields futures as they complete (finished or cancelled futures). Any futures given by fs that are duplicated will be returned once. Any futures that completed before as_completed() is called will be yielded first. The returned iterator raises a concurrent.futures.TimeoutError if __next__() is called and the result isn’t available after timeout seconds from the original call to as_completed()timeout can be an int or float. If timeout is not specified or None, there is no limit to the wait time.