[PATCH] D126815: [llvm] [Support] [Debuginfod] waitQueueSize for ThreadPool

[Noah Shutty via Phabricator via llvm-commits]

noajshu added a comment.

I agree with @mysterymath there is more than one way to support this usage pattern and I also agree with @mehdi_amini that the user code could keep track on its own.
It seems like this ought to be a common scenario, that there should be an unbounded number of files ( / modules / sections / etc.) to be processed, but bounded memory. User code will be slightly simpler if `ThreadPool` provides a standard API to handle such cases.

I suppose another direction would be to abandon the producer-consumer model altogether. In D114845 <https://reviews.llvm.org/D114845>, this could be done (in part) by letting the threads share access to the `recursive_directory_iterator`, acquiring a lock then advancing it on their own to harvest jobs from the filesystem.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126815/new/

https://reviews.llvm.org/D126815