Sync, Async, Postfixes why bother?

[danielmarbach]

The library provides both sync and async versions. Some methods are only available as sync APIs, the sync APIs sometimes reuse async APIs internally and are subjected to deadlocks because of context capturing. Some methods are postfixed with async when they return a task. Sometimes not.

the client is mostly pure IO based using HTTP calls. .NET Framework already moved into pure async APIs with the new HTTP client. Embrace async, make the whole library fully async. Remove the sync wrapper by embracing Async All the way. It's time to move into the async world ;). Get rid of the postfixes, see our reasoning for NServiceBus. This makes the client code and API calls simpler to compose (embracing concurrency and asynchronisity). Synchronization for sync environments is now up to the caller (makes is a top level concern anyway). Your libs becomes simpler to maintain because you write less code. Because you think async first you minimize the risk of using "older" concepts like ThreadAffinity, ThreadLocals ... and design upfront for async (floating state, no more ambient context...)

Btw. Quartz.net is also moving in this direction (I admit I oooh so gently pushed ;) )

https://github.com/quartznet/quartznet/issues/331

[cskardon]

Please excuse any naivety in my questions here!

So - on the postfix side of things - it makes sense if the whole library is Async - so that's all good. In your view - is this a big (as in time to do it) change?

I assume this would be a major version change (semver wise) as Results would now be ResultsAsync and that would cause breaking changes?

[danielmarbach]

Yes it would be a major.

Switching to async only seems to be involved especially on the transaction side of things. The rest seems to be pretty straight forward

Am 20.04.2016 um 12:14 schrieb Chris Skardon notifications@github.com:

Please excuse any naivety in my questions here!

So - on the postfix side of things - it makes sense if the whole library is Async - so that's all good. In your view - is this a big (as in time to do it) change?

I assume this would be a major version change (semver wise) as Results would now be ResultsAsync and that would cause breaking changes?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

[xied75]

Just check if this is still waiting in the queue?

[cdwiegand]

I know this is an old thread, but as a developer who is NOT moving to async everywhere, consider making separate async and sync versions that don't use each other maybe? Async infects code by requiring you to move your functions to async all the way up the chain, and does not work well with threading or callback functions. It's a nightmare to debug. Think MQ libraries, or threaded HTTP/TCP servers - they're already multi threaded, and don't need async.

I know, I know, "async is the big thing, everyone's doing it", but some of us like being able to manage thread pools - our downstream developers don't run GUIs and so don't benefit from async everywhere.