(In reply to Jens Stutte [:jstutte] from comment #2) > So I am fine with being more resilient when we can, but if a pool has no thread and can't get one from the OS, we should probably rather always crash than return an error (and then maybe crash, maybe hang). Since this api is to dispatch a task to a pool of threads, including the caller's thread in the pool for temporary is reasonable for some cases if not all cases. For my case, I dispatch a task to a thread pool to avoid IO from blocking the current thread. If the thread pool fails to have any thread, doing it in the caller's thread is acceptable. What do you think to have a function like `DispatchMayCurrent()`? This function could run a task on the current/caller's thread if it fails to create any thread.
Bug 2009073 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jens Stutte [:jstutte] from comment #2) > So I am fine with being more resilient when we can, but if a pool has no thread and can't get one from the OS, we should probably rather always crash than return an error (and then maybe crash, maybe hang). We should be able to degrade the service. Since this api is to dispatch a task to a pool of threads, including the caller's thread in the pool for temporary is reasonable for some cases if not all cases. For my case, I dispatch a task to a thread pool to avoid IO from blocking the current thread. If the thread pool fails to have any thread, doing it in the caller's thread is acceptable. What do you think to have a function like `DispatchMayCurrent()`? This function could run a task on the current/caller's thread if it fails to create any thread.