Makes perfect sense! Thanks @ktoso. Apologize for I rushed a little.
Could you comment on how to convert a long-running synchronous function into an async function, which can be leveraged by task group for parallel executing?
runDetached the correct API to do that? Even the child task is not expected to be detached?DispatchQueue.async inside runDetached?Task.checkCancellation() inside above dispatch queue?You’d have to define what you mean by “long running”. It’s a bit of a “catch all” phrase which makes discussions a bit harder since it’s so imprecise.
For example, if you mean a) “long running because processes 2000 elements” then sure — make it an async task and just checkCancellation every few elements. if you mean b) “long running because it’s blocking” these proposals can’t change this since they are cooperative cancellation, we cannot prevent a blocking IO operation in some low level C API to randomly respond to our notion of cancellation (without going off process).
I would encourage not thinking about threads but tasks, and everything these proposals talk about be confined to tasks. Tasks may share a thread, or they may not — it’s up to the executors used by the runtime to decide that.
Thanks @ktoso. Both replies are crystal clear and enlightening.
Can you please clarify (or point me to some resource that does clarify) why you're not inclined to swap actor class for actor? To be honest I think this sentence alone is not clear enough. Do you mean you're not inclined to make actors a separate nominal reference type without inheritance like @Chris_Lattner3 proposed or you mean you're just not willing to change the syntax for declaring actors?
I meant both. I just posted a detailed response to the pitch to make actors a separate nominal reference type. I recommend that we resolve the semantic issue before debating the syntax.
Doug
I turned this into a little dependency diagram.
Doug