ProtoPromise best practices?

[drew-512]

Hi! Love ProtoPromise so far, thank you!

Long time veteran but only doing C# and Unity a couple years and currently wrapping my head around async/await. I'm trying get best practices in how ProtoPromise should play with Task<T>, ValueTask<T> and async. Assume Unity 2022.1 and later.

Suppose you're is building an awaitable suite from scratch using ProtoPromise -- where principle calls tend to be awaitable "all the way down" until they reach things like web requests, file loads, and embedded library calls.

I would love to simplify and replace everything wholesale ProtoPromise but I find the whole ValueTask<T> with async so friggin confusing. It's tricky to understand what doesn't generate unneeded garbage -- any advice or convention suggestions are appreciated.

Thanks ~ Drew

[timcassell]

Hi Drew,

ProtoPromise should be able to completely replace Task and ValueTask for all async methods that you write.

For any existing APIs that need to work with Task or ValueTask that you do not control, you can convert to/from ProtoPromise by using the task.ToPromise() extensions, or promise.ToTask()/promise.AsValueTask() extensions, as mentioned in the readme https://github.com/timcassell/ProtoPromise#task-interoperability.

but I find the whole ValueTask with async so friggin confusing

Basically, that behaves the same as Task<T>, but is more efficient if the method completed immediately. ProtoPromise has that same optimization built-in.

It's tricky to understand what doesn't generate unneeded garbage

It's safe to assume Task and ValueTask will always generate garbage. There are some instances where they will not, but it's simpler to assume they will. ProtoPromise will never generate garbage*, unless you have object pooling disabled. *[Edit] See comment below.

Does that help?

[timcassell]

.Then really exists for old runtimes before async/await was available. Tbh, async/await is much more readable to me.

As for which API is more efficient, it really depends on your use-case. You would have to benchmark it, and in most likelihood it will be a negligible difference. .Then uses a bit less memory if you only need to append a single callback, but if you need to chain multiple .Thens together, async/await is lazier, so you might end up using less memory that way. But it's not always the case, so you would need to measure it yourself. Also, the memory used is pooled either way by default, so it may be difficult to measure.

1 advantage that .Then has is it automatically normalizes progress for you, while you need to normalize it manually with async/await if you use it.

I would default to async/await.

But since it's nice to have a version of DoThing() that can be used with .Forget() (rather than the caller having to make it an async call)

I'm not sure what you mean by that. Either your function is declared as async Promise<bool> and you use awaits, or it's declared as Promise<bool> and you use .Then. it's returning the same type either way, and the caller will consume it the same either way.

Also, there's a bug in your code. Promise<bool> p = Promise<bool>.Resolved(true); is not forgotten if someRequirement() returns true. You should forget it, then assign the new promise (or better, assign it in the else clause).

[timcassell]

Also, it's easy to accidentally allocate garbage through closures by using the .Then API. async/await doesn't use closures, it stores all the state in a backing state machine, so that's not something you need to worry about.

[drew-512]

Awesome, thanks. I think I'm starting to get the hang of it.

As a relative newcomer to C#, I've been reflecting on why it took me so long to really get the ins and out of async await. I think it's been a combo of noise (tons of people who write or post on stack overflow that really shouldn't) and excessively voluminous enterprisey docs such that ya get a lot of fluff and specs but rarely no "this is what's happening under the hood" as a way to help understand and use it effectively. That's why I've been such a Go fan since since my C++ days -- the language and runtime spec is purposefully small.

Anyway, thanks again for ProtoPromise as its made async await enjoyable to use in Unity!

[timcassell]

Ha, yeah. People tend to complicate async/await, but it really is as simple as, "pause this function, and continue after the awaited task is complete". Other more complex things should come after getting that basic idea down.

but rarely no "this is what's happening under the hood"

Believe me, I did a ton of research while writing this library, and at times I just had to look right at the source code to see what the heck MS was doing with tasks. Their APIs are ridiculously complex. I think I simplified things enough to be easily approachable, while still providing the tools necessary to do more complex things when necessary.

Anyway, thanks again for ProtoPromise as its made async await enjoyable to use in Unity!

I'm glad to hear it! ❤️

[drew-512]

Exactly -- you expose the perfect amount of complexity (yielding simplicity). And in rare form, C# type-safety and conversion does the rest without adding more hoops. :D That you also bench and QA against Unity is huge and underrated. ProtoPromise is literally a prayer answered.

So many C# packages either fall down in Unity, are bloated (Google.Protobufs), or have painful dependencies (e.g. Microsoft.Logging etc). An example of that last one, I've been wanting to switch to Capn Proto but I don't have the C# chops to get it the C# version of it building and linking under Unity. As this prototype hits more milestones and funding is unlocked, my plan was to use this Unity friendly impl of CapnProto or and/or sponsor development for it. Now I want to see if it will integrate well with PP.