How do I flush synchronously?

[mgravell]

How do I flush synchronously?

[mgravell]

I'm very rarely going to actively advocate calling sync-over-async, and this is no exception. If it works for you, fine - but: on your head be it. Ultimately, the answer here is "pipelines is designed as an async API; there is no synchronous flush". The intent of FlushAsync() here is for implementing back-pressure, i.e. where your writes are overtaking the limits that you've configured. When you flush, what it mostly does is make sure that the data is being actively written, but if you're over the limits, it also has the chance to say "just wait a moment until the data clears down a bit" - it will then resume the writer when there is obvious capacity in the pipe.

On a nearly empty pipe, you won't really see a problem from sync-over-async, as it will almost always be synchronous anyway; however, when you start hitting the limits (i.e. there's a backlog in the write queue), you'll find yourself blocking the writer thread(s), which could start a "spiral of death" if all the blocked writers means that there's no available pool threads to do the writing.

On your head be it.

[RayKoopa]

Thanks for the fast reply. I'll look into reworking this kinda legacy code base then to support async properly, I just wanted to ensure I'm not missing something before I delve into that.

(It is indeed not the first time I have problems with my legacy sync code - I initially tried to use the StreamPipeReader provided by the System.IO.Pipelines package, but its TryRead does not even ever return true unless one called ReadAsync before, which is why I tried your library as it happens to work in that case.)

[Kaelum]

@RayKoopa I know this is closed, but you should read up on how to properly use the "async" system. You should never use any property or method of an async call, when calling from a synchronous method. The proper action in this case would be:

Task.Run(() => client.Connection.Output.FlushAsync()).Wait();

Calling any async method and attempting to access any property or method directly from it directly, while inside a synchronous property or method, can cause a threading deadlock at any time.

[RayKoopa]

@Kaelum Thanks, I'm aware of this; the project which lacked proper support for asynchrony for which I opened this issue has since been reworked/rewritten to be fully asnyc and no longer requires a workarounds.

[mgravell]

using Task.Run(...).Wait() would retain much of the wrongness; arguably marginally better, but a small margin

…

On Wed, 1 Sep 2021, 17:58 William Bosacker, ***@***.***> wrote: @RayKoopa <https://github.com/RayKoopa> I know this is closed, but you should read up on how to properly use the "async" system. You should never use any property or method of an async call, when calling from a synchronous method. The proper action in this case would be: Task.Run(() => client.Connection.Output.FlushAsync()).Wait(); Calling any async method and attempting to access any property or method directly from it directly, while inside a synchronous property or method, can cause a threading deadlock at any time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMDPRKIUZL7TS7W7AXDT7ZLRVANCNFSM43OPSLZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.