<div dir="ltr"><div dir="ltr">Robert Engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> ezt írta (időpont: 2023. aug. 8., K, 18:12):<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">That’s the point. It is an abstraction that allows flexibility. You have the same concern if your sync blocks on a semaphore indefinitely. </div><div dir="ltr"><br></div></div></blockquote><div><br></div><div>The point is to move away from async, and an API that explicitly promotes async is misleading at best when the code you are writing by definition is synchronous. That is, it conveys to your client code (by type) that you somehow wants to run things asynchronously.</div><div><br></div><div>Also, it is not exactly the same:</div><div><br></div><div>1. It does not conflate concepts (async + concurrency restriction). So, it is a lot less likely that somebody just submits a task to it, ending up calling back to the executor.</div><div>2. More importantly: It is trivial to improve the naive semaphore based implementation to be reentrant depending on what is the actual need for the constraint. The same behaviour would require a custom implementation of ExecutorService (and would still be problematic, if multiple thread pools are being used, instead of writing plain synchronous code), and an ExecutorService is way more difficult to implement.</div></div></div>