[AI Task] Fix async-bridge TCS inline continuations and Post<T> permanent hang in Tizen.Applications.Common - #7808
[AI Task] Fix async-bridge TCS inline continuations and Post<T> permanent hang in Tizen.Applications.Common#7808JoonghyunCho wants to merge 2 commits into
Conversation
…guard Post<T> runner exceptions (Fixes #7736) - AppControl.SendLaunchRequestAsync, CoreApplication.Post<T>, CoreTask.Post<T>: create TaskCompletionSource with TaskCreationOptions.RunContinuationsAsynchronously so awaiter continuations never run inline inside the GLib main loop dispatch. - CoreApplication.Post<T>/CoreTask.Post<T>: wrap runner() in try/catch and route exceptions to task.SetException, preventing a permanently incomplete Task and exception propagation across the reverse P/Invoke boundary. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
| catch (Exception ex) | ||
| { | ||
| task.SetException(ex); | ||
| } |
There was a problem hiding this comment.
🤖 [AI Review]
🟡 Suggestion: This catch (Exception) triggers CA1031 (Warning in build/Global.ruleset) in analyzer builds; the same GLib-dispatch pattern in TizenSynchronizationContext.cs suppresses it explicitly.
| catch (Exception ex) | |
| { | |
| task.SetException(ex); | |
| } | |
| #pragma warning disable CA1031 | |
| catch (Exception ex) | |
| { | |
| task.SetException(ex); | |
| } | |
| #pragma warning restore CA1031 |
| catch (Exception ex) | ||
| { | ||
| task.SetException(ex); | ||
| } |
There was a problem hiding this comment.
🤖 [AI Review]
🟡 Suggestion: Same as in CoreApplication.Post<T> — this catch (Exception) triggers CA1031 (Warning in build/Global.ruleset) in analyzer builds, which the assembly elsewhere suppresses with a pragma for this dispatch pattern.
| catch (Exception ex) | |
| { | |
| task.SetException(ex); | |
| } | |
| #pragma warning disable CA1031 | |
| catch (Exception ex) | |
| { | |
| task.SetException(ex); | |
| } | |
| #pragma warning restore CA1031 |
|
🤖 [AI Review] Automated review by AI assistant |
Suppress CA1031 via pragma around the GLib-dispatch catch blocks in CoreApplication.Post<T> and CoreTask.Post<T>, matching the existing TizenSynchronizationContext pattern. Applied-AI-Comments: 3793036964,3793037206
1 participant
Summary
Fixes the three async bridges in
Tizen.Applications.Commonthat createdTaskCompletionSourcewithoutRunContinuationsAsynchronouslyand completed them from GLib main-loop callbacks, which could run arbitrary user continuations inline inside the main loop dispatch (stall/deadlock risk). Also fixesCoreApplication.Post<T>/CoreTask.Post<T>so arunner()exception no longer leaves the returned Task permanently incomplete (caller hangs forever onawait) nor propagates across the GLib reverse P/Invoke boundary.Changes
src/Tizen.Applications.Common/Tizen.Applications/AppControl.cs—SendLaunchRequestAsync: create theTaskCompletionSource<AppControlResult>withTaskCreationOptions.RunContinuationsAsynchronously.src/Tizen.Applications.Common/Tizen.Applications/CoreApplication.cs—Post<T>: addRunContinuationsAsynchronously; wraprunner()in try/catch and route exceptions totask.SetExceptionso failures fault the Task instead of hanging the awaiter or crossing the reverse P/Invoke boundary.src/Tizen.Applications.Common/Tizen.Applications/CoreTask.cs—Post<T>: same fix asCoreApplication.Post<T>.Mode
Refactoring
Verification
dotnet buildon Tizen.Applications.Common — 0 errors)Public API signatures are unchanged; the only behavior change is on the exception path (permanent hang / process crash → faulted Task, matching the Task contract).
Fixes #7736