16424, “mppf”, “sync blocks and library helper tasks”, “2020-09-19T13:25:32Z”
If a library uses begin to create a helper task, wrapping the library call in sync will lead to a hang.
(Issue #16387 discusses approaches to a similar problem with serial).
Consider a library that - somewhere deep inside a call - needs to create a task in order to function correctly. For example, it might need to create some kind of helper task like a progress thread. If the program calling the library makes the call within a sync block, then the call will never complete (because the helper task will be waiting for more work). We could say that the sync block shouldn’t be used if such functions are called - but that property is hard to see when the sync block function calls to libraries and the helper task might be deep within those. Would documentation for all library functions need to include a note about whether or not it is safe to call the function in a sync block?
I know of two strategies to resolve this:
A. Create a task team idea - which, in a way, is like naming the sync block so it can be stored in a variable and tasks can be created that track termination with a variable instead of the sync block.
B. Provide a mechanism to de-register a task with the currently enclosing sync block and instead register it with the outemost one (which is checked at the end of main). This approach is sortof like disown in bash.