These are chat archives for NimbusAPI/Nimbus

20th
Jan 2016
samousavih
@samousavih
Jan 20 2016 00:32
How slow it might be to use interceptors for that purpose. Do you have any metrics or used them before?
Ashley Mannix
@KodrAus
Jan 20 2016 01:37
What problems are you having with synchronization contexts? I barely think about them
Andrew Harcourt
@uglybugger
Jan 20 2016 02:07
Mapping from async to sync is fraught with hidden traps.
We only really do it in one place and I wish we didn't need to.
(IEnumerable<TResult> in multicast requests.
)
Ashley Mannix
@KodrAus
Jan 20 2016 02:12
Ah, is that in the CorrelationWrapper?
Andrew Harcourt
@uglybugger
Jan 20 2016 05:01
Yep; the multicast one.
It's taking a task.Result within a while loop.
I'd really like to make it not a thing but I also really want to keep a simple IEnumerable<TResult> signature.
I spiked an IAsyncEnumerable<TResult> last night and the calling code looks a bit ick. It could be made a bit nicer but it's still a non-standard enumerable thingy.
(I'm only hitting this particular issues because of some strange behaviour in the StackExchange.Redis client when using async operations.
Ashley Mannix
@KodrAus
Jan 20 2016 05:09
Is the spike on Github, or did you keep it local? It's such an innocent looking bit of code too. Are you getting deadlocks or something with the context switching?
Andrew Harcourt
@uglybugger
Jan 20 2016 05:10
I still have it but it's in a local stash.
I can reproduce the deadlock when using async with StackExchange.Redis and using a custom single-threaded synchronization context.
For the moment I've changed the Redis client to use the synchronous calls and it seems happy.
It appear that there's a known bug in the Redis client so I'm not that concerned with it now.. just that sync contexts in general are a pain.
Ashley Mannix
@KodrAus
Jan 20 2016 05:20
Interesting to go through, I haven't actually bumped into sync contexts much. Hopefully it's patched soon, it'd be nice if you could async yield in this case
Ashley Mannix
@KodrAus
Jan 20 2016 06:08
What if you did something like:
var response = _responses
    .TryTake(remainingTime, CancellationToken.None)
    .ConfigureAwait(false)
    .GetAwaiter()
    .GetResult();
Andrew Harcourt
@uglybugger
Jan 20 2016 06:53
It's still going to block the calling thread :(
The .ConfigureAwait(false) in this case won't make any difference as we're not actually hooking a continuation to it.
Andrew Harcourt
@uglybugger
Jan 20 2016 07:20
Async yield would be very cool but the state machine logic involved in doing something like that would make for some very interesting hoops for the compiler to jump through.
Ashley Mannix
@KodrAus
Jan 20 2016 08:00
Ah right, so the issue is where it's blocking, not where states 1+ are picked up? I reckon it could be done. Didn't people say the same thing about await in catch blocks? I'm not seeing an API that's nicer than what you get with IEnumerable<T> either
Andrew Harcourt
@uglybugger
Jan 20 2016 11:40
Yep.. The issue is that the thread that is blocked can also be the thread that is supposed to handle a continuation which will only be scheduled for after the current task has been completed, which will never happen because the thread is blocked :)
The compiler could be made to do the async enumerable thing; it would just require a bunch of effort that misty went on just getting Roslyn out the door..
*mostly
Ashley Mannix
@KodrAus
Jan 20 2016 22:11
Looks like there's already plenty of discussion about it going on: dotnet/roslyn#261
Right now, it looks like the way to go is Rx, but it'd be silly to pull in that dependency just for a single API
Andrew Harcourt
@uglybugger
Jan 20 2016 22:13
Plenty - it's been something that people have been wanting for ages.
Ashley Mannix
@KodrAus
Jan 20 2016 22:14
Slated for C# 7?
Andrew Harcourt
@uglybugger
Jan 20 2016 22:15
Many things were maybes for C# 7. If it's definitely on the list then that's good news :)
I really don't want an Rx-style approach for this - it doesn't mesh well with the mindset. It's much easier to conceptualise multiple responses as a single set rather than an observable.
The kind of thought pattern is "Does anyone think this transaction looks fraudulent?" or "I'll take the first three sets of recommendations that get sent my way". That's really easy to express with LINQ; not so much with Rx.
It's entirely feasible; just guides people into a different thought pattern.
Ashley Mannix
@KodrAus
Jan 20 2016 22:28
Yeh, I know what you mean. You'd probably end up wrapping an observable back up in an enumerable anyway to get the design, and then why use it at all when you can write your own async iterator.
I can't tell if it's definitely on the list, it was assigned to the C# 7 milestone, but it looks like they've rejigged them since then. Will probably have to dig through design notes to find out
Damian Maclennan
@DamianMac
Jan 20 2016 22:29
it's going to be called C# 1 Core
Ashley Mannix
@KodrAus
Jan 20 2016 22:30
That's right, I forgot about that world-shattering revelation