Skip to content

Investigate having custom SynchronizationContext that handles async void #4709

@Youssef1313

Description

Seems reasonable I'd guess. I'd find the behavior more intuitive if it behaved like xunit does: xunit registers its own SynchronizationContext in order to make async void work, both in terms of knowing when the test completes and knowing when an exception occurs. async void still isn't recommended, but having one doesn't put the whole process in jeopardy.

Originally posted by @stephentoub in dotnet/docs#44419 (comment)

@stephentoub Would you expect the custom synchronization context to also "preserve" thread apartment state after an await? Currently, if we have a test method marked as STA, I think the code before the first await will be STA, but the code after may not because it could end up on a ThreadPool thread. Or do you think it's fine to end up non-STA after an await?

cc @Evangelink @MarcoRossignoli As we have had previous discussions around that area.

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions