.Net Foundation Design Reviews, 15 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitHub Quick Reviews

Description

Issues Discussed:
* dotnet/runtime 52079: Rate limit APIs
https://github.com/dotnet/runtime/issue/52079
* dotnet/runtime 51927: Logging-Generator should allow to skip the IsEnabled check
https://github.com/dotnet/runtime/issue/51927
* dotnet/runtime 53875: Obsolete HMACSHA1 constructor with useManagedSha1
https://github.com/dotnet/runtime/issue/53875
* dotnet/runtime 19459: New Type System.Runtime.CompilerServices.DependentHandle(TPrimary, TSecondary)
https://github.com/dotnet/runtime/issue/19459

Chapters:
0:00:00 Rate limit APIs
1:17:48 Logging-Generator should allow to skip the IsEnabled check
1:22:15 Obsolete HMACSHA1 constructor with useManagedSha1
1:24:40 New Type System.Runtime.CompilerServices.DependentHandle(TPrimary, TSecondary)

A

Api for to support that, so I think this whole area needs to be thought through, because the path that the string that we're talking on here ends up with asp.net, not using anything. That's on the screen, at which point. Why are we doing it? So it sounds like there's a missing piece here.

B

Yeah, I think there needs to be potentially more thought in terms of like how these updating values will work, but um I've been trying to also not uh add too much complexity right now for the uh the rest of the uh essentially values and interactions.

B

uh I think it's a little bit more later, that we can uh add in terms of uh supporting uh options that mutate.

C

So I recall talking about this a bit in the past, and I remember concurrency limit was the thing that was brought up as tricky when config changes um yeah. I remember talking to you about that john and um you were the one who brought that up and um I think, though, for like what you were saying is like for some of the rate limiters and stuff.

C

um If asp.net middleware reacts to like an eye options, monitor change, we could probably create a new rate limiter instance to use for the middleware, with the new options for for certain things that might not work for concurrency limiting, but something to consider.

B

Yeah the concurrency was tricky, particularly because its accounting is very exact and it is um triggered off the off of release, which is why I think I originally said it. It could be tricky, but um we, I think um essentially dealing with new incoming requests, is not so bad. um It's just this case of like. um If you increase the limit, then we should start uh processing the queue again uh or any acute requests which uh yeah that needs a notification of some sort.

B

A

So I I I think it's fine to say you know we're not currently going to support the the mutating scenarios. But if that's the case then.

D

A

Revisit like concurrency limiter options should be sealed and none of its property should have set.

B

Right so yeah. um The reason why I didn't make a sealed and have setters is to kind of suggest that we can do these mutable options, but we can start off with them sealed for this iteration, and then we can talk about designs on how to support mutable options um like we can start that discussion, but we can also proceed with these apis.

B

E

All right so we're making all the options type sealed.

B

A

Or the very least, the ones that the ones that don't work well with mutation once the limiter has been created, should be sealed with no setters right. It should be you construct the limiter options and, after that point the values, don't change for the ones where you have designed it already to be fully mutable. It sounds like some of these are um then I, while I generally prefer things to be sealed by defaults. Unless there's a good reason, um it doesn't have to be.

B

I think we can just start off with all of them sealed and see where the implementations like once they do, support it. We can unseal them and make them mutable.

A

Also, I mean separately, it begs the question for something like concurrency limiter options. um If the pattern is you're, just passing data into a constructor and everything is only gettable, is there a reason to just not construct the concurrency limiter with those settings.

A

Not having options.

F

B

I think that I mean that's a possibility.

B

But uh I mean again part of this was to kind of suggest that you can use the default implementations with uh other types of options.

B

Sorry, I didn't understand that you can use what with what so, essentially the things we ship inside this assembly would be these options. But theoretically asp.net can uh extend a concurrency limiter option and uh have it uh mutate based on configs and stuff like that, uh but I think, uh but they can't, because.

E

We just sealed it and made all the properties.

B

But yeah yeah, so I think uh essentially having config driven options uh can be designed for uh later and we can just seal them for now.

A

I'm refreezing what you're saying john, I think, you're saying in in the long term. You believe you will, we will add necessary surface area to concurrency limiter options, to support mutability, to support notification when something changes, and so the right middle ground right now is to ship it as sealed immutable, but later we'll remove those constraints.

B

Yeah and I need to essentially think about the scenario like essentially asking that core yeah, we will definitely use uh you, know extensions options uh or essentially figure out how to make that work. Well, uh but in cases where um you know you're just working with runtime bits, it doesn't make sense to um have a dependency on options. I would say no, because theoretically, we want these to be usable uh in inside the bcl, which is where we hope to eventually put it so having it depend on extensions options, is not a good idea.

A

Do have a higher level question you've mentioned a couple times, asp.net extending stuff here, maybe shipping, its own implementations. That makes me a little nervous if that, if we're saying you know here are default, implementations but asp.net can't use them, because that then suggests that we're shipping things that you know if aspirin can't use them. Why can can anyone else? Use them right or are they gonna also have to create their own because of this or that constraint they have. So what are the?

A

What are the special situations that would cause asp.net to need to create its own and how are how is that.

B

Not the common case, I think it'll depend on um integration with other, um I guess uh library, so, um for example, um asp.net core. It actually sits on top of extensions and all that, so we can make use of uh extensions uh concepts such as config and and uh options and stuff like that, but we don't want it to be so that you can only use rate limiters. If you have those concepts. So uh can we have like a slim down version where it has fewer dependencies, but maybe the options are not mutable. For example,.

B

I'm not sure if that makes sense.

A

Yeah I mean, I think, it'll be interesting to see how this plays out. If we end up in a world where, um uh how do I say this, I would be sad if we shipped these types of you know supported in whatever, in whatever form we eventually end up, supporting them and asp.net is unable to use them um or or or more generally, uh there are.

A

Everyone ends up needing something special in the implementation, such that no one can really use the ones we ship out of the box.

B

Fair enough.

E

So I'll re-ask a question steve asked, which is if right now, the way that you're expected to use concurrency limiter is new concurrency limiter of new concurrency limiter options of specify all the options.

D

E

How about we get rid of the middle new and just delete all the options type and make them parameters and their constructor.

D

E

And then, when we have support for an options, type that is dynamic and all.

A

E

Then add it then.

B

Okay, that makes sense yeah.

B

C

Yes, oh okay! Sorry so would we be using this with eye options, though, like in the middleware like that doesn't require like a new, concrete implementation of the limiter right.

C

G

How do you flow the updates into it.

E

Yeah, well, you can't it's.

B

A constructor yeah, but.

E

You can't, with with them being get only and sealed.

C

Yeah, there's yeah, it would be uh middleware right, so the middleware would be taking the eye options, monitor of rate limiter options, whatever.

G

But how do those updates get passed to the rate limiter.

C

I think so you would recreate the rate limiter for the ones where you could. I mean.

B

Yeah, essentially, I think that's what that is, which is uh we have a wrapper for these uh for these implementations that uh and then in that wrapper it would take in an eye options class and when those options changes, it um creates a new uh instance of these limiters and, uh like essentially, it goes through its. I guess, all the cued requests and move them over to the new.

B

um I guess uh concurrency limiter, for example,.

G

How do you get access to the queued request.

B

You would need to track everything. That's in there. I would assume, uh essentially shim or essentially have a bunch of so in the wrapper before it returns the task that's being awaited. It would have some kind of accounting to track all of the currently outstanding requests.

C

Yeah, if we wanted to make it separate like constructor orgs, you could hoist everything to like middleware options and maybe that's okay. I don't.

C

E

All right so yeah we're flattening all the options in the constructor overload or into constructors.

H

B

Okay, so I think we we were on concurrency limiter options.

B

Did we want to move on to token bucket.

E

All right, so, I think for token bucket. We already had the comment that it shouldn't mix the naming of permit and token so yep.

C

Again, with the flattening on the constructors, are we at all worried about like too many constructors, I mean isn't that the normal reason for the options pattern? Is we decide? We want to add more configuration later and then we just end up with too many constructors.

B

Right so mind you that uh in this case, it's a little bit different being that uh most of these values are required. So, for example, concurrency limiter. You need to specify all three.

E

So like when we add one.

F

E

So, like a new optional thing, my guess um is- and I guess the way that I was proposing. The suggestion is that in this v1e preview, everything it's flattened parameters and if v1 goes stable and never got support for the you know, update notification, options, types, etc. Then you know that ships when something comes along later either. It's a constructor overload to add the new thing or at that point the options types have been worked out and there's now two constructors, one that takes the rich options type and the other takes the flat static parameters.

E

And if you want whatever the new feature, is it's only on the new dynamic type? And and that's that's that, but it's sort of like if we ship the options type now before we understand what the options type needs to do to fulfill its long-term vision. Then we may end up with two constructors anyway,.

C

But this like guarantees, we end up with two constructors like don't we want to like be closer to the final shape of the api that we would want.

B

uh Put put on our way, what are the drawbacks of having a options class and only one constructor that takes in the options class.

E

I mean if having the options type be a sealed type with get only properties. It's just you look at it and it's like the way that I build. One of these things is new thing. I want of new thing. I want options of all the parameters. Why do I need to specify this other thing in the middle?

E

So it's just uh the usability looks weird uh if, if it makes sense in the average consuming scenario here that you would have built some options and you're using them across multiple instantiations, then that would be a reason to have the type. If it's uh you expect that in the next you know like right after whatever v1 is you think that there are going to be?

E

You know, six more options that you want on one of these things, and maybe the options type is already justified now, but looking at it from when we talk about future plans, they often never come to fruition. um What's the options, type really bias.

E

Yeah, okay, um like so.

D

E

Otherwise, I'm just asking the question like fewer types means fewer things that people have to think about, uh and that's why I suggested uh just squashing: it just usability, etc. If there's scenarios to already have the types now, then fine, if you think that you can implement the the notify semantics on them later, then that is a reason to maybe go ahead and do it. I just ask questions.

C

So yeah, like the direct constructor arts, don't do notifications either, so I guess I just don't see the downside of sealed options. Types like we use it like in you know for sll stream, a lot of things where you just have a lot of options and I think, given the design space here, it like the future, like the ability to not have a ton of constructor overloads is nice and I just don't see the downside. Maybe is the new type really that costly?

C

E

I mean really again it's just a question of: is it just noise for the ssl stream? It's there are a lot of options. Many of them don't need to be specified. I believe it like it does the I have some required things and then settable properties for optional things- and this is everything- is required, except auto replenishment on the token bucket rate limiter like at that point, it's like if ever again, it's if everything's required. Why are you invoking two things um right.

B

So I mean in the token bucket limiter, which is up next. uh There is already a optional um parameter, or at least that that is one of the possible designs. So um so there is a case for having these optional parameters, but in this case there's really just one.

B

Yeah, I think it depends on like whether it's better to be a bit more future-proof.

B

I I think like we can also just try out the implementation, see uh uh whether we identify newer parameters and uh whether a option is.

B

I personally, I think I do prefer having option classes as well, which is why I proposed it here, but in terms of simplicity, I'll refer to your opinions, if you feel that collapsing them down to a constructor is better to start.

B

Do you have thoughts, emo.

E

I mean not really. Okay, I mean. Sometimes you have insights from usability studies of when thing people comment that things feel unnecessary. So.

I

Yeah I mean I, I get the argument for both sides. I think that the problem is like I'm, not an expert in this domain, so it is very speculative right. That's why I think you know when I said earlier, we should ship a preview and see what happens right. I mean I would generally like as a principal. I would shoot for less pieces and then just see how people react to them, because you generally don't get feedback that there are too many pieces right.

I

So if you think it's worthwhile cutting things down and then only added when customers complain, I think it's probably easier to ship with fewer pieces than v1 or, I should say, be preview right.

B

Perhaps but uh I would actually like to um kind of argue that, having these uh options, though, yes, you do need a new limiter of new options, um it might be uh better than having eventually having this bifurcation of multiple constructors as well. So like less uh and like less of what.

D

B

Yeah, I think I'll keep these options then.

B

um Anyways, I think I'll move on to the actual settings for token bucket reloader options um so yeah the permanent limit, cue limit and cube processing order. Those are we've kind of already mentioned those. The three new things are, one is a replenishment period, so this is when does replenishment gets called on the token bucket um limiter and the other, which should be an end token for period, is how many tokens get replenished when replenishment happens, and essentially those two values, replenishment period and tokens per period.

B

That is um that defines your rate in this case.

E

Okay- and I think and that's- um and we already discussed this- it's it replenishes up to the the token limit right and.

E

Is there a is, it is some? Is there a model that people can understand about how replenishment and queuing works like the q limit.

H

Plus the replenishment.

E

Period is the q.

B

Limit a hard limit that never grows or what so, essentially, you can queue, requests up to the queue limit and when replenishment occurs, if there are cues, if there are requests that are queued, then we will process them in either fifo or lifo order depends on what you configured and try to satisfy those requests. When replenishment occurs,.

G

How are we rectifying permits and tokens here.

B

Equals the tokens and then.

G

I it's a token bucket rate limiter that has a permit limit.

E

It has a token.

G

Yeah that that's the thing right should permit limit be named token limit.

B

E

I'll change that yeah we uh we had already discussed that one when steve got very said it was confusing, but the base.

B

There is no base.

G

E

There won't be.

G

B

Big class it'll just be those properties will be, there will no longer be rate limiter options and those three values are going to be renamed appropriately for each uh options. Class.

G

Okay, I missed that part. I was gone beginning, okay, that satisfies me. Then it's all token.

B

Yeah similar concepts but different names, yeah and then um the next part will be kind of interesting uh with essentially auto replenishment. So the idea is that, by default, the implementation, if it should essentially trigger these replenishments by itself and how we would probably do that is via a timer but there's a drawback to that, which is what, if you have a lot of token bucket rate limiters to just create, essentially create a bunch of timers as well and essentially that being potentially inefficient.

B

So the idea is that we have this option to say whether you should create those timers and track those replenishment yourself, but also for token bucket rate limiters. Have a public uh replenish method that you can call.

B

Essentially, if you uh say, let's say you have a hundred uh rate limiters, what you would do is you would set all of those auto replenishment to false and then have one timer uh that triggers and every time it triggers it calls replenish on all of these limiters and, depending on the different periods that you've configured, you might want to call this every second or call this every.

B

You know whatever period that you externally control, but uh it will still respect the replenishment period, setting that you have specified so that, if time elapsed since last replenishment period is greater than what you've specified for that particular limiter. It'll do a replenishment otherwise it'll just no up. So that's the idea that or that's the reason why this auto replenishment property is there to facilitate that. uh We have had other thoughts on like how that can be achieved, but so far this seems like the simplest and the uh most.

B

uh I guess convenient.

E

So the concerns that I would uh or that I'll raise with that are, if you're using one external timer to drive things and it's using the same replenishment period. You can end up with mild skew where the outer timer thinks that you know one second has passed, but the inner thing thinks only 0.9999 seconds have passed and now it actually doesn't replenish and you miss a period.

E

I also think it's weird that a a method whose name is entirely replenish sometimes doesn't so and we've gotten rid of all the setters, because we didn't want uh complex state here, so I my recommendation would be that the time span becomes nullable and null time span means it's externally replenished and not in all time span means it's internally replenished but either way, and then you can decide if calling replenish and you gave it a time span is an exception or if it's just like whatever bonus replenishment period.

E

But that's how I would do it of I. Basically the time span says I'm in control or you're in control.

B

I see, and essentially um so this goes back to the. uh I guess uh idea that if you had a hundred uh limiters and one of them uh essentially is supposed to get replenished once every second and one replenishes every minute, uh the external- um I guess method needs to know which one should be replenished at the one second mark and which one should be only replenished.

B

E

Minute that is the thing that seems natural to me. um I could be wrong, but.

B

That I mean, I think that works it's just um then you'll need to kind of have a mapping of like limit her to time span, um whereas this essentially uh like the idea, is to kind of decouple that a little bit and have the replenishment period always set and auto replenishment determine whether that is being uh like uh checked externally or internally. So I think again like this is probably just an alternative um way of representing it, and uh it shifts the responsibility of who keeps track uh of these uh replenishment period around.

B

Should that be on the limiter, or should that be external, um it will be even simpler to to make that an external responsibility, but I think that makes it harder to use.

E

E

Yeah, I mean, I guess the yeah, my so with the the method which you know requires jumping ahead a little bit, um but the method being just named replenish like if it was attempt replenish that could do it or like I mean, because the question is, if you're this external thing, that is just being a a single timer, doing a bunch of pumping and you're, not knowing or you're, not tracking who's supposed to do what probably you're just going to run through and for each thing. Do it.

E

But right since, depending on what kind of timer you're using if you're using a leading edge, timer trigger, then the amount of time you spend in context switches in your for each loop or you know, no ops versus actual work in the in any of the limiters can start throwing off uh the what looks like the rising edge inside the methods that you're calling.

E

So right, the the call to me it feels like it should really be authoritative um and then the other method would be.

E

You allow this time span to be passed in and then you just expose it on the uh as a time span on the token bucket rate limiter, uh so that the caller can match that against its own sense of what it was supposed to do. But anyway, like you're, going to end up with clock skew in the external thing, unless the replenish method is authoritative and because you know clocks are hard.

B

Yeah, I would say that this really should depend on the uh how these limiters are uh are used. So, um for example, if- um and this is essentially the end creator of these limiters should be the ones uh aware of how to um I guess trigger these. uh I would say that, for example, if you, um the concern, is clock skus, uh then the uh these attempt um replenish should be called at a frequency that is higher than the actual uh replenishment period.

B

uh So essentially, if most of your uh limiters are you know per second, let's say you should really trigger replenish like once, every half second, or probably like once, every quarter second, or something like that, so that uh even if you have a little bit of clock skew, you should be able to recover pretty quickly. Now, if the difference is that you have a wide range of uh replenishment periods, obviously you know you have services that uh meet different. um I guess contracts like essentially you know.

B

Some limits are, I don't know five requests per week and other things are like uh you know, requests per second, uh so then, in that case it might make sense to have uh separate timers for them, and just let and assuming you know, you have maybe like uh five different rates that you configure like you know, per day, limit per second limit and a per week limit. uh Then it probably makes more sense to have each of them have their own timers and you don't need to like essentially check everything all five of those limits.

B

uh Every you know half second, so I think it depends on the end user, who created these timers to determine whether they want to like create a timer per limit or use one that is common across all of them, and I think this makes that a little bit simpler, assuming we renamed the replenish method.

E

uh That's fair, I guess yeah just having or saying that you'll have docs. That suggest. If you turn auto replenishment off that you call the attempt replenishment or whatever it ends up with the final name. At a.

E

Multiple times per expected period, just to avoid clock skew, I think that would help.

B

Okay, um yeah, I'm not sure if we want to go dive right into the token bucket um implementation, uh but we can also just go through the rest of the uh fixed window and sliding window options. If because they should be quick.

E

Yeah, um I guess one question because, as I updated a bunch of insta longs in the notes here, uh all the permit limit and q limit should both be longs. They should be it's.

B

Like everything should be ins, um I realized I copied uh different parts of this uh proposal from different times. I guess and I didn't update all of the uh counts, but all of the accounts should be in. um We decided to do that so like and all the accounts are related to each other, so they show all just begins.

B

E

um I think I have that fixed though.

B

Okay, okay, so let's go with fixed window, then.

E

um So fixed window, that is um sorry back on uh token bucket rate limiter options. So if we got rid of all the setters, I guess this moves to a default. Constructor parameter.

B

Yes, okay, that seems like to be the.

B

B

uh Okay, so fixed window um rate limiter uh a brief explanation of what that does, so it should be almost considered the simpler, uh the simplest kind of rate limits. Essentially, you define a window which is a time period where the permit limit applies. So, let's say your time period is one second, and your permanent limit is like 10. That means 10 operations per second, you can change the window to be longer like operations per day per hour.

B

Anything like that and the per milliliter is just how many operations you can do in that window and the implementation on the implementation side. Essentially the you track the beginning of the window, as well as the count that you have seen in this window and once the beginning of the window is rolls over to like the next one. You reset the count.

B

Right: okay um for sliding window, that's a little bit more complicated in that.

B

Essentially you split up each individual window into different segments and then you roll over instead of rolling over on a new window, you roll over on a new segment. So an example of that. I have an example in the design dock, but I'll just describe it here. Let's say that your window is three seconds and you have three segments per window. That means each segment lasts, one second, so what happens is on each new? Second, you shift all of the counts that you uh account for um uh over.

B

Essentially, you add one new uh segment and then you remove the account of the older segment and then the total of all of your segment is your account for that window. So I think the original implementation of this. uh The idea is that a fixed window is a little bit jagged too jagged, and this sliding window makes your traffic a little bit more smoother.

E

And if you wanted pure sliding window, then you would just specify segments per window equal permit limit, uh sorry, a pure sliding window. What do you mean uh the if the oldest request that I'm tracking is less than sliding window time, then we're good to go?

E

Basically you and that implementation ends up with a linked list of times that you saw things that grows to the permit limit and starts popping things off the head like there's, but if you, if you wanted like, if I look at the request logs at any given time, I should be able to see you know we.

E

We went up to the possible permit limit and not we hit this artificial chunking of oh, you were only tracking at half second windows, so we ended up queuing even though that one should have ideally been in the previous window.

B

uh I see so uh in terms of queuing uh your um your so in the sliding window case every time the segments roll over you essentially get a piece of the uh permanent limit becomes available, essentially right of how.

E

Many were in the segment that just got popped off.

B

Right but uh it doesn't mean that you can immediately process uh like it doesn't mean that the permit limit is completely reset, so it really depends on yeah exactly how many uh permits were in the uh segment that you just popped out.

E

Right but if you and if you pass segments per window equal one, that's basically the exact same as the fixed window right yeah.

B

Correct, in which case you probably don't need a sliding window right right, number right.

E

Yeah, oh, I see you even had it previously uh yeah uh using properties of the same name but with a different source. It means I need to copy that one into right.

E

B

Okay and then it's all of the limiter implementations and uh so for concurrency limiter. It is pretty much just all implementing all of the parts of um rate limiter, plus a constructor, so nothing too out of the ordinary. uh There are a few private things on there. For example, it would have a private release method that gets called in a private class that implements the permit lease which keeps up track of the account and when that lease is disposed, it'll call release on the rate limiter, but all of those are.

B

Private, okay, I think I'll. uh So then we can move on sorry.

E

Are there any no as a financer um are there? Is there any value in having.

E

The object expose what it thinks its current settings are, so either exposing off its its options as a property. That's just one property or exposing the pieces, and, if, like, I think that would really only be useful in the debugger and in the debugger. You can step in and look at the internals, but it's just a question.

B

um I would like to say no until proven otherwise, um because I I don't, I haven't, found any scenario that is um useful like essentially once you create a limiter, the only thing that you should really ask it is hey. Can I do a thing.

B

E

I mean but, like you know, the the base class got, you know get available permits um right. So then it's like well, you know there's some reasons you may want that in in some flows, and otherwise it may just be sort of a semi-diagnostic.

E

I don't think any of these things have a way of reporting how big their their queuing state is right now, uh just because that didn't seem useful at the time, and uh so it's just looking.

H

At the shape here.

E

Of uh like there's sort of a a suggestion that people really like if they gave a thing in a constructor that they can see it later, so they can line things up with. Oh, this is the object that I created here and it's over here, but if you're only really gonna have one, then it's it's the one and you built it and you know what it's doing so.

B

Right so I mean yes uh in terms of like that could be useful, but uh the scenario that you mentioned essentially like how big is the queue? How what's the health of like, like how many permits are being used and stuff like that?

B

uh Those are what we designed the metadata to be and those values, essentially how many things are into queue and how many outstanding permits those are very dependent on the specific moment that you try to acquire something which doesn't really make sense to be on the options to be exposed via options, for example, and the options really are are just hard limits that you have set in the beginning.

B

um I don't think as like, even if you, as a library, right, you're, passed in these limiters, you don't really need to know, or I mean that's even a little bit more different because you can um like uh sorry what I was trying to say is uh as a library the only uh concern that you should be.

B

Having is, uh I want to use these limiters to specify by the user and and limit some kind of operation, but you shouldn't base that decision off of um like limits that were configured on the off uh on the.

E

Sort like I could be wrong, I'm just thinking you're past a rate limiter and if you see that it has a maximum permit count, not even just looking at a current what's available, but seeing that it.

D

E

A a maximum of 30., but you think that you can have work, that's represented in the hundreds. Then this means that you would need to figure out ways of chunking your work to fit within 30, because uh you know 187 is literally never going to succeed. uh Even if the q limit said you would have 500. Presumably that's going to throw of.

E

I will never be capable of fulfilling this request, because there will never be 187 free at one time so seeing things like what's the hard limit or what's the the maximum request that you would support, I mean I think it would be very weird to be in that state, but it seems possible- and this is it when you're doing a thing where your your count represents an amount of work as opposed to you know, just the requests per second of I'm a request so yeah in that.

B

Particular scenario, I would argue that there's a miscommunication between the library, authors and the end users, essentially the library authors- should be. um You know uh clear about what those uh numbers represent. For example 180, as you mentioned, that could be bytes, uh maybe and uh if the user specified, you know, you can only ever work on 30 bytes at a time, then yeah. That library is just never gonna progress, because you can never get those permits, and I think that makes sense, and it's just either the user.

B

I need to up their limit, or um you know the library author should be clear that yeah I we only do chunks of work in 180 bytes, so you better specify a pretty a higher limit, or else I'm not going to proceed.

E

Fair enough- and I don't remember if we talked about it when we did the abstractions, but certainly if I call acquire with negative one- that's an argument out of range exception. uh But if the hard limit is 30 and I call it 187, what kind of exception are you expecting?

E

Because it's not.

B

It's not appropriate.

E

To be an argument exception at that point, because the general rule is argument, exceptions could have should always be able to be pre-validated.

E

I see so if there's no, if you can't ask what's your hard limit, then it shouldn't be an argument exception because you couldn't have known it was going to fail so argument. Exception means you should have known this wasn't going to work, uh go rewrite your code and other types of exceptions are due to a confluence of events. I'm sorry. We cannot proceed further.

B

So that is a good distinction. I did not know that um and in my proof of concept I also use an argument exception. But uh after what you mentioned, I think then it should just be an invalid operation. Exception yeah, you just.

C

That's invalid right! Sorry, what's the invalid operation exception exactly again.

B

So if you um have configured a permanent limit of 100 on the rate limiter, but a request came in via acquire to require 180, that's just not going to work, because the limiter itself only has a maximum of 100. So we will return on.

C

Ioe and why that, rather than immediately returning a lease with his acquired false, so.

B

B

uh I believe, oh sorry, okay, actually let me let me check what I oh yeah. I.

E

Mean, if that's what it does it's fine just. I think.

B

I might have uh added the check for that, but I returned false. Instead of throwing through an exception- and the argument exception is, I think, only for negative numbers.

E

B

Really it was just.

E

If you can't ask what the what the maximum for a single acquire is, then it shouldn't be an argument exception. If it's returned false, then that's fine.

B

um Yeah, let me just double check, I think.

B

Oh, I made an argument out of range exceptions, but yeah returning false, probably makes more sense.

B

Yeah, um I think uh there might be a distinction on like um essentially returning false, is almost begging for a retry, but an exception is like no just don't even retry.

B

So that could be a distinction of like whether it's throws or not, but I think that I think we can talk about that in the actual implementation. Pr.

E

That's fine, I'm just taking the note for that. We talked about the exception model and any implementation detail you want is fine as long as it's not an argument exception, because that violates the argument exception. Normal usage.

B

uh Let's see right, I think that was concurrency limiter uh for the token bucket limiter again, uh it is kind of similar in that it's mostly a constructor, plus the uh implementation of the rate limit, limiter abstractions, plus the public replenish method that we were alluding to earlier.

B

If we don't like the name, we can make it a try replenish and have it return a bull on whether it replenished or replenished or not. um I think that's an alternative I can think of. Although I don't know what the external uh triggering would do with that pool uh information.

E

I mean depending on, what's doing it and whether or not it cares it would log it.

B

Yeah potentially, uh but essentially the reason why I didn't have uh it returned anything or used or tried method is, I can't think of why you would need to uh oh, I need to do a public void there. Rookie mistake uh coding in markdown is uh yeah anyway,.

G

uh Yeah, so we dismissed jeremy's idea about making replenish, authoritative and then having the options. Take a null time span.

B

So I feel that that is harder to use, because essentially what you need to do is externally. You need to map a limiter to a time span, essentially you're tracking, that information elsewhere uh and- and it's like.

G

Figuring out how to do that, even with this design.

B

So with this design, uh all of the information about like when replenishment occurs, is encapsulated on the uh token bucket um uh options and.

G

You're externally telling it when to replenish, so you just.

B

Always replenish.

G

It more often than what it's configured to yes,.

B

So, essentially, uh in terms of clock, skew and stuff like that, uh it is better to essentially trigger these uh several times uh per uh over a period so that your clocks could don't like uh skew too much.

G

Are quote unquote normal people gonna? Think of that, if they're like, oh, oh, I have two of these. I want to not have two timers. I just want to base it up a one-timer.

G

Are they gonna.

D

G

Why I should fire that, timer more often than than the lowest number I put into the two limiters.

B

um I mean that is a recommendation. It's not a hard rule. If, in some I don't know in some scenarios, you might not want to uh trigger it, based on the even the most frequently updated limiter.

B

It might not be replenishing as frequently as it could be, but maybe that's what you want is. Essentially you only want to update every 10 seconds, regardless of how it's configured, but essentially in 10 seconds. You might, you know, replenish a token bucket multiple times. That could be what you want to do. I don't see why or like right now. I think that is really up to the user, uh how they want to do it.

B

We can recommend that if you have multiple token bucket limiters, you should uh when you create them, you should trigger their replenishment, um based on, like the most frequently updated bucket and also multiple times that, but that's a recommendation rather than a hard rule.

G

Just feels like a super advanced scenario that the majority of people are just going to get wrong anybody who's going to try. This is going to do it wrong for the first time.

B

I feel also, if you're in the advanced scenario, where you're triggering these externally, then you should be a bit more careful. I I expect most first-time users to just use auto-replenishment and end up creating a.

E

Timer yeah, I mean because even that's not necessarily accurate, like if the system's thrashing timers get laggy right right.

E

A

E

You know void attempt replenish bull, try replenish, um you know it's complex, weird things like replenish. If able um able seems weird, but.

B

uh Yeah, none of those uh words just like when I was thinking about it. I was like I don't like any of them. Let's just make it avoid, but yeah I think we'll try replenish, might make sense, and then we just I don't see a use case for that bull really uh right now, but I mean I think, returning a ball is: isn't bad per se.

B

Any um anybody have any opinions of replenish versus tri.

G

Replenish, I mean, I definitely think if it doesn't, if it's not going to replenish, it shouldn't just be named replenish.

B

G

I I definitely agree like if it's not actually going to do if there's con scenarios, where it's not going to do what I told it to do, calling it just replenish doesn't make sense.

C

Can we call it like tick or something.

B

So um the reason why I call it replenishing is because, um like token bucket, I guess the concept um generally have like a refill or replenished concept, and I've uh named all the parameters accordingly, like essentially replenishment period or something like that. um So that is why I call this method. Replenish.

B

In terms of like tick, I I think I'm not sure how, uh if that's a very uh that's a name with a lot of uh meaning behind it, um but uh yeah. So I mean I, I want to get everyone's feeling on that.

E

uh I mean tick yeah, I don't. I don't see that being a. um I think that anyone would find other than the documentation for auto refill, saying if it's false you're expected to call tech and then you'd be like well. How often am I supposed to call it and then that's just like it is very much not a self-describing method um yeah. So um try replenish attempt replenishment uh check replenish um like because the the verb is what you want the object to do right, and so if the verb is replenished, then it should replenish.

E

If the verb is you know, try, then that means it can fail. If it's attempt, then okay, that's the same as try. If it's checked, then that's exactly what you want it to do check to see if it's time to replenish and then, if so, do something about it. uh Actually, you don't care.

E

If it does something about it, you just told it it needs to check, and um so it's the verb should represent the in you know the thing it's going to do and I don't have opinions on any of the things being a a a zero argument. Try, on the one hand, is a little weird.

E

On the other hand, it seems okay, it's just that like there are things going on, it's just dependent upon the state of the object and the state of the clock, and so it's two pieces of ambient state that are merging together and it tells you what state they were in and yeah. Maybe no one cares about the the return value, but it's the try pattern. So it's the tripadder.

B

I think I like the try pattern instead and I agree with eric that replenish sounds authoritative and it's weird that you caught replenish, but nothing happened. So I think try, replenish and returnable is probably better in that way: okay, okay, yeah and then the rest of the fix window and sliding window. um uh Last time, when I talked about it, I was I think I mentioned that uh they should probably also have a replenishment method.

B

But actually I don't think that is the case, because these are um essentially just depending on your uh current time and time stamp and whether you should refresh or not, um and essentially they should be uh triggered uh actually.

E

I mean it's just all down to logic and acquire and or release right, so they're triggered by you needing to do something.

B

Well, the only thing is uh when, when you're queued with weight, async core and essentially, how does that get? How does qt processes get triggered or get processed, and actually, I think, yeah essentially try uh or try update window, probably not replenish, but like some. Some other kind of tri method is needed um to essentially allow external triggering of these uh window based rate limiters as well. So it's essentially all the replenishment and uh auto replenish um properties apply to these as well, um but yeah.

E

So I should add those I mean void refresh, makes sense to me.

B

Yeah, okay and then auto. I guess refresh.

E

B

E

But now the question is that now that you've brought up having a manual refresh, does that mean that you want to go back and add the option for? Should it yeah, because it.

B

Seems for auto refresh um okay, yeah it'll be like auto refresh window or something like that and then um try refresh window yeah try refresh window on the limiters.

B

B

Yeah, so I mean another question: is um I guess in terms of naming it's it's probably better to have replenish for token bucket and refresh for window ray limiters, um but they are essentially the same concept and I'm wondering if we should extract like uh time time-based rate lender abstraction that you know provides a singular uh method for calling refresh or uh replenish and having a time-based rate limiter option.

B

That has a you know, auto, um I guess replenish or refresh, because they are very similar concepts and having it the same concept but slightly different names, but does the same thing pretty much and you work with them in the same way, I'm not sure if that is preferable or having an abstraction, is better.

E

I mean if, if you think that there's reusable logic of you know time-based refresh.

E

Then you can certainly add one, but I think now you have to figure out what the what's the signaling mechanism it's supposed to use right. So the timer goes off how's it supposed to notify the derived types uh that this is the the timer event and things uh I mean it could be that it has.

E

You know abstract bool, try refresh, and it just calls that, but then you're using refresh instead of replenish on the token bucket one. So it would be reasonable and uh but the good I mean the good news, is you can slide it in later right? uh You, okay, fair enough.

B

E

Add new base classes and that's not a problem, so you don't have to solve that today.

B

Okay, um yeah, then we'll just keep the more uh limiter specific language and uh we can combine them later uh stephanie. I think you wanted to say something.

C

Yeah, I was just wondering if, like the reusable thing, was more general than even rate limiters, where it's just like. I want to subscribe to like a heartbeat kind of thing. um I mean that would be periodic.

E

C

um But yeah I mean at a certain point like timer is what you have but yeah right, but this is supposed to be more efficient than that. If you already have a way to call it periodically right.

B

Yeah, I I think I was looking into patterns of how to subscribe to heartbeats. At one point, um I didn't find anything uh authoritative on the subject. So, if you have any ideas on how to subscribe efficiently to a heartbeat or like, where are some gotchas and know-hows that we can talk about how that could.

B

B

um Yeah, that is all of the public apis for the implementations.

E

All right, um a thing that you said you didn't or weren't sure that you were happy with was, I think, the the names of the things in queue, processing order, yeah.

B

Yeah, like the enum, I don't know if q processing order is too long or not descriptive enough and also uh kind of like process oldest process newest. um I think it conveys the idea of lifo and fifo, which is pretty much what we're trying to do here, but um yeah, um I'm curious. If anyone has better ideas of how to name it.

E

I just wonder if we already have this enum somewhere, that can.

B

Be reused so a example of something similar is uh bounded channel full mode.

B

uh It has drop, newest drop, oldest and drop uh incoming or uh yeah dropping coming or essentially, basically idea that if a bounded channel is full and a new request comes in which one do you drop, the oldest the newest or the incoming one?

B

um That is slightly different from this, which is uh when a refreshment comes in. Do you process the oldest or the newest right? I think the reason for that is any incoming ones. They if they already exceeded the q limit, just it makes sense to drop those incoming requests.

B

uh It doesn't, and also that is very uh similar to uh kind of lifo.

B

So yeah dropping the newest and dropping the incoming. It seems very similar, essentially.

G

B

G

Have the option like dropping the incoming's always gonna happen.

B

G

Because wade sinks, weighty sync's gonna, get called, and it's like well you're you're over the limit and the queue is full you're done.

B

Right right and, and that I think, makes sense um and like essentially there's no distinction, like I don't feel like having a distinction between uh process newest and not dropping incoming, makes sense, then you're just thrashing on the newest thing in the queue.

B

So so, essentially, what I'm trying to say is it's. It is uh functionally different from down to channel full mode, but it's because I think, thrashing on the new request doesn't make sense for rate limiting so yeah. There is precedence, but I haven't found specifically this like.

E

G

Or do we not like how it's called process, or what do we like about the enum.

B

um Personally, I think cue processing order is a bit long, but I don't know if that's uh a big concern.

G

Does it have to have the word q in it.

E

Yeah because I mean technically speaking, uh though uh our priority queue already violated this, but technically speaking, that queue is fifo right so, and I think that was so. It's really request processing order.

G

I mean why not just processing order or.

D

Process oldest and.

G

Newest, you don't even need process in, though right because you're already, in the rate, limiting it's two words, so it's kind of at least not it's not just one word that we hate.

E

Yeah I mean processing order could be slightly too overreaching in general, but the fact that we don't have one yet is.

C

G

Yeah I mean- maybe you still have. Maybe the name of the property is still cue, processing order because we called it a q limit. Also yeah, that's true right, so that kind of has to go together.

G

But if the enum is just named, processing order oldest and newest yeah.

B

I, and I also didn't um I called it- a q limit, particularly because I don't know what else to call the limit other than q. Essentially, you want to say, like he's, got kind of like the waiting request limit.

E

Standby uh yeah standby weight.

G

Overflow- I don't know if I like that either but.

B

Yeah I found that q probably conveys like eighty percent of the meaning, which is, uh as I've been told, naming should be just eighty percent accurate.

E

Yeah I mean, I think, it's I think, cue processing, order's fine. um uh I was going, uh I can say this, but the person who said it in the chat will just have to take it on faith. I was going to suggest renaming them to oldest, first and newest. First that same suggestion came up in youtube, chat.

E

But I like that.

B

Okay, yeah. That sounds pretty good too.

G

So keep the enum name the same, but the values drop.

E

G

B

B

C

So why did we drop or why did so we're keeping key processing order as the name of the enu? Yes, okay and not processing already, because I like that suggestion, what was the the downside? Not enough cue.

E

D

E

I mean it's once if there's a feeling that the property should be called q, processing order to tie it to cue limit and that the parameter should be queue, processing order to tie it to q limit. Then why isn't the enum just called cue processing order to tie it to the queue limit? Okay, yeah? No, I got it. I missed that. Probably thanks.

G

E

So just value affinity, um okay and now now that we have a mostly concrete shape, uh I will ask: do you think that the the processing order is something that people really want to think about, or do they generally want oldest first, and it should be a defaulted parameter on all these constructors.

B

um So that's a very interesting question. I would generally say that uh it might be unintuitive but, for example, asp.net core or like in web scenarios. Oftentimes. You don't really want to do things in order, because if something is waiting in the queue for a while, it's probably already cancelled itself.

B

So if you are trying to be fair and essentially always process, the oldest one first by default, it might lead to more um like failed requests anyway, so that that is why essentially lifo order is is pretty, is in some scenario better uh and it's better to process requests that you think have a likelihood of actually still wanting those results uh rather than being very fair. um But in other scenarios you know, fairness makes a lot more sense um in in terms of like uh well, not not exactly concurrency, but.

B

In producer consumer kind of uh scenarios uh it may it makes a lot more sense to be fair and and use uh process oldest kind of um by default there. Which is why I don't know if it's a good idea to set a default value for it, um because I think it's really dependent on the scenario and it's better to have whoever's using it to really tell us what they want.

E

Fair enough and then similarly- uh and it sounds like the answer- would be: no- should there be an enum member, basically the zero value of do whatever you want.

B

But wait: uh what do you mean by do? Oh, you mean like a custom queuing order.

E

No well that that you're telling the token bucket rate limiter, you don't care like cue, processing order. I don't care, do whatever you want.

B

Oh interesting.

E

B

Would be cue, processing.

E

Order uh unspecified or any or default uh or yeah, probably default.

B

In that case, then, I think we should be opinionated about which one we do for default, um which is something I would like to avoid, but um again.

E

If you don't think it makes sense, then that's yeah.

B

Fine, I mean uh there's also an interesting question. I'm kind of uh surprised that.

E

B

E

You are opinionated because zero is always the the easiest thing to use. You just write default and it'll be the zero so oldest. First is your implicit preferred option right.

B

So, um theoretically, the enum isn't um complete in terms of like you could, instead of just having a live or a fifo order, you theoretically uh can't have an implementation that implements some kind of priority queuing um granted in uh these scenarios uh there they could be, um or essentially in the implementations, I've seen uh most people just defaulted one of these, and uh so we don't. uh I I've not added any like either custom or other or or you know, other processing orders in here.

B

um Essentially, if you want those, then write your own limiter and uh implement your own options, um because the default ones that we ship, I think, should just come with fifo and lifo and uh essentially be done with it so yeah. So that is, I guess, I'm not sure if anyone will question why we didn't have uh more values, but that's the kind of reason why I kept it to just uh oldest verse in the us first.

F

C

E

E

Right didn't actually mean to be there, so that's fine.

E

All right, so we renamed the q processing order members. We got rid of the rate limiter options, base class and lifted everything to the drive types we removed all the property setters and sealed all the types or all the options types um we said token bucket should unify on token. Instead of have a mix, and we talked about some exceptions, we changed replenish to try replenish and we added what I wrote down was try refresh and auto refresh.

E

um So I added got a refresh equal, true and a boolean property and similar on sliding and we'll try refresh.

B

E

All right is there anything we talked about that. I didn't write down or anything else that anybody wants to say on this.

E

Issue all right, 5.75 hours, plus all the meetings that went into it.

B

I'm very uh help.

I

Did we talk about the assembly.

B

It would be the same name as the uh uh name space, so system threading, ray lifting.

I

And then that goes for the new get package too correct.

E

Yeah we yep good talked about that in the previous meeting.

I

And uh shipping wise, you know with your shipping out of your yeah, which report your shipping out of.

B

uh It's yeah. Our plan is to ship it out of asp, labs under preview and then, uh depending on the feedback we can put it like, essentially push it lower down in the stack.

I

E

B

Thank you very.

B

E

um Mr tobe left us, I believe.

E

F

Mr harder, are you with us uh I'll be doing this.

D

F

um We might need a bit more time than the 10 minutes that we have left.

E

That was where I was going with the question, so I.

H

Have a 10 minute or like a shorter one, I think.

E

Okay, well, this one is another marked as blocking that we should.

H

See if it looks short.

E

Yeah, of course,.

I

I hope I think yesterday said it will take a bit longer because it's the whole stream builder stuff again yeah. I think I know where this is going, but I think this needs some discussion.

E

I

What was yours.

H

It's the seventh sixth one in the list um logging generator should allow to skip, is enabled check.

D

Nice and if we do this one fast enough, I also have a relatively small one that would uh it's not top down blocking work, but it would unblock a partner team. Are.

E

You above or below mine,.

D

uh It's the one literally below it.

I

All right, so it's walking all right.

H

So uh eric erhard, if you're, also on the call um this one, is just adding a um flag for the constructor yeah uh right there, just one more, but it's optional, uh that's the only so, basically I'll go for the background of why we need it. If you remember like about skip enable check um overall, we if we when we have a logging generator uh if we know that the person who wants to write, wants us to auto generate the log method.

H

If they already have uh guarded their method in a is enabled check, then the generator wouldn't need to guard it in this enabled check itself. Therefore, in the way the consumer would, let us know to skip that would be through the attribute here and that that's it.

F

G

This is the same name.

F

As the runtime.

G

Api right just skip enable check.

H

D

Make sense to me.

C

Approved, I think it would make sense to.

E

Sorry, I'm formatting things for uh looking good in the.

E

E

Any concerns going once.

E

H

E

Thank you for having a short one, okay, um so in crypto, which means everybody just stopped listening uh in dot-net framework 2-0 or like a 2-0 preview or something weird, um the there was a a bug in how uh sha-2 h-max were computed, and so there's these properties called produce legacy values and they we just ignore them in core and so marking them obsolete.

E

Now that we're obsoleting things and additionally, the hmac sha-1 type, had a boolean of, should it use manage sha-1 for managed hmac instead of using native sha-1 for managed hmac, it turns out, we don't even do manage hmac anymore. We do native hmac, so this boolean is ignored and if you're calling it, you should just call the other constructor so things that have never worked in core that now that we're obsoleting things we should obsolete.

E

That makes sense to me, and I feel, like kevin, may, have missed hmac shaw, 256, so I'll just leave a note of check that one too.

E

And demo we're always using ids now, yes,.

I

um What do you mean by always using ids.

E

All the things we're obsoleting we're obsoleting with distinct ids. Now.

I

Oh yes, I mean basically the idea is that yeah, we should just always apply an id when in doubt apply an id like these are cheap.

I

E

E

I like, when me typing, is the limiting factor.

D

All right so for this one, uh this was originally a different proposal and yawn eventually said that he thinks we're doing a disservice by not just exposing dependent handle directly so uh dependent handle is an internal type.

D

That basically means that if one type is uh is being tracked and the gc should correspondingly track another type and it's basically what powers conditional weak table behind the scenes, uh this proposal is effectively take dependent, handle and expose it publicly with a couple of tweaks, um and then there were, there were three small open questions which were largely decided below but which we should uh confirm are correct uh within the concept of api review, namely uh there was push that we should have this be disposable and therefore free should be disposed.

D

um There was a somewhat related question of should we just go ahead and do the same thing on gc handle as well, um and then steven uh raised. If we're going to have it. If we're going to have it be free, then, uh should it be uh a a static, alec mesh method instead of a constructor, um but given that we're that it was decided, we should go with dispose.

D

I think I'm thinking uh the constructor should be kept, um but otherwise it's relatively straightforward here um and then the only other question was uh for target and dependent property. Should that be a method, get target independent or should it just be a property?

D

But it's effectively as described relatively straightforward.

E

I think I would make it a method if nothing else, so the debugger doesn't accidentally keep it alive. Every time you hit f10 and you're near it.

D

E

I guess if target's already a property, it's already going to keep the target alive.

I

E

C

I

The target independent property.

D

What what do you mean can not.

I

Like like, do we need this strictly speaking, because the thing, instead of doing that, I would either implement the decomposition pattern. So you can.

H

I

Decompose the handle into target or dependent or just that people access the individual things.

D

The reason why it's two is because you could conceivably have a tear, otherwise the the property can be implemented such that it returns both simultaneously ignoring any mutations in between, whereas separate target and dependent returns. You could theoretically call target mutate, one and then um uh and then return dependent, and they would no longer be in sync so to.

C

Speak and since they're the same type, is it a little more documenting to have a couple returning property or method than destructuring.

I

Yeah so, like I mean the deconstruct method would do the same thing, but you could also do it because you basically return it as alex at that point. Would they be named, though yeah they're out parameters.

C

D

Yeah, but we've recently switched to using tuples for these apis, where we want it to be a logical thing that the jit can optimize.

I

I mean the nice thing with the decompositing, though, is that if you ever need to add a third one, you can I mean it's.

D

Never going to happen here that this is a very specialized type, which is why it's in compiler services, that is specifically it's basically a a thing similar to gc, handle it's basically never going to change. It's always going to be a target independent.

E

E

Sure yeah I mean.

E

Why do they need to be get set.

D

uh Because that's how they are today, uh dependent handle as it's used by conditional weak table, allows you to get or set the values. It is not a read-only.

E

E

Well, but conditional weak table uses this as an implementation.

D

Right and ideally, we would expose this and then be able to continue using the exact type we're publicly exposing internally, otherwise, we're kind of defeating the purpose of exposing this publicly.

E

Fair enough, I'm just like I'm just confused as to when it would actually update target like. I can see a scenario why someone would want to update target updating dependent is you've used the the override or the overwrite syntax, um but when is conditional, weak table updating target.

D

Not sure, but it has the method there and I'd, tell you via source.net, but source.net is still down yeah. uh The type is fairly well documented, though including reasons of like getting the secondary objects more expensive than getting the first, which is why they expose uh the ability to get just one or the other uh or both um etc.

E

Yeah so again, like with the with the properties being properties, if you're in a place that has this object, there's an increased likelihood that you're introducing heisenbugs, because the debugger is going to investigate target which is going to prevent it from getting garbage, collected or possibly prevent it from getting garbage collected, which means the dependent will possibly stay around longer. So seeing one of these in the debugger I mean, certainly they can be marked as non-display, but that then makes them not usable in the debugger. So.

E

It just yeah, it seems a little weird, but I don't super duper care the having the property return. A tuple does feel weird. It just feels more.

I

Methody I mean my bigger concern. Is it's just it's just more things to type. If you have a decomposed method, you don't have to access the property. You can literally actually decompose it into target independent, which seems a bit cleaner to me.

E

Indeed, because our basically.

I

E

Is if you're doing this, we expect that the only thing that someone's going to do is decompose. It.

D

Right but that's natural if you've got a property or method and are returning a tuple.

I

But the thing is: if you do the decomposing, you don't have to do dot at all that we can just say you know var t comma d equals dependent handle right. You just have to type less.

I

Right because the compiler handles the deconstruct method.

D

Right, but you can naturally just deconstruct this right. You can just.

F

D

Very very target comma underscore equals target independent, and that gives you just the one you want.

E

Well, handle dot target independent if dependent handle had public void, decompose out, object, target out, object, dependent. Then you would say target comma dependent, equal handle right.

C

Is there an argument that properties are more visible than deconstruct methods.

I

I mean maybe I mean I think it depends on how I mean this is probably a type where usability isn't the high order bit right. So it's just, I guess mechanical is lower than I think it is, but.

D

Right for the with this api that it's a extremely specialized type, that's going to be getting used by performance, oriented people that are writing things like custom, conditional, weak tables and your you likely want it to be usable by them and not necessarily friendly for other people. In my opinion,.

C

Yeah I mean I don't necessarily agree with the premise that, like advanced apis, don't need to be nice to use, but, like I I get it it's not as important as like dictionary apis.

I

What's less about being being more easy to use is more about. Do people who use this api have an intuitive understanding of that you can decompose it right and the answer to that might be yes right. I think that.

E

I mean I do feel that, while having a decomposed means we get to avoid the is it a method or is it a property um that, if I called the dependent handle handle, it would look really weird to me to decompose a handle.

D

Right and you, you really want to think of this as a target and dependent, not as other things and target independent, is what was landed on rather than primary, secondary in the discussions that happen below between mayoni and the interested parties that are wanting. This exposed.

E

Yeah I mean I don't really like either of those names but don't have better suggestions so.

D

It's the fairly standard name for this type of thing,.

E

Okay, so this is a mutable struct um which we don't like, but it's a weird thing and.

E

And so it I assume that this is not backed by a reference thing that makes it safe right. It's just it's just as unusable as gc handle, because it's just as yes, it's a single in pointer.

E

And yeah, so I mean you mentioned, you know having this one thing means you can avoid the state where, like one of these two changes during that time, it's immutable struct. It certainly shouldn't be being accessed on by multiple threads.

D

Likely not, but it's still the the way it's set up today in the way that's going to be usable by the parties interested and for conditional weak table itself has the ability to to get both simultaneously, as well as the ability to get just the primary. uh The the way it's actually implemented by the run time today is a get primary and secondary method. That's an internal call to uh to the jit.

E

um Meaning it it's basically the tuple call or it's two methods once again, primary ones get secondary.

D

No, it's a single method; okay, because what's what it's represented as a single endpointer for for both handles um and the the runtime does magic to make all of that work correctly.

E

Yeah, I think, for reasons I can't articulate just artistic style that this feels more like a method than a property, um and then, ideally, these, I think, would be methods uh for debugger display reasons. But um if so, they being.

D

E

Makes more sense than whatever.

D

They are methods today on the internal dependent handle. The discussion below um ended up ultimately landing on properties, but I'm not sure if there was a particular preference there either way.

D

uh Jan was the one in particular that suggested properties may be more appropriate for all three of them.

D

A couple more up is where john said it.

E

John questions, the tuple method as well.

E

E

Okay, apparently.

B

E

D

Yeah there was a lot of discussion here on making sure that this was the correct shape covering the right things easily usable. Hence the discussion on. Should this be disposed or should this be free, etc?.

E

Yeah, so I agree that in general, a thing that is get set feels like it should be a property, um but given the the purpose of this and the way that debuggers behave.

E

I would suggest that it I mean either that we debugger or tell the debugger display to not show these properties uh or we just make them get and set methods explicitly and everything's a method, so nothing the debugger does not introduce heisenbugs unless you explicitly call a method on it.

D

I think that's a reasonable feedback and um we can discuss with yon, which one is the most appropriate. He feels um I'd. Imagine that we could just worst case have a debugger display proxy here um just to to avoid the issues of keeping things alive, etc, but also given it's an in-pointer.

D

I expect there not to be too many.

D

E

All right so should we just go ahead and change them into methods here and see if we need to switch them back later.

D

I'd probably keep them as properties because john's the one that suggested that in the first place and then raised the concern and then yon would indicate uh if he thinks that's valid, and we should just change it to get set or if he thinks it's not a a concern, and we should just keep it as the properties.

E

Okay, but I do again, I we don't have a rule for it, but it's definitely a I guess we do it's. It's slower than accessing a field um that the target independent should be a method and not a property, because it's just it feels very weird as a property.

E

Not but mostly that's an artistic feeling.

D

So my own view here and I I don't think this should block anything, but my own view here is that the only reason people think that it feels wrong is because it's a tuple if it was a struct and therefore did not expose that there were named properties here. No one would be batting an eye at it, um and so I think, from that perspective, since a tuple is just a struct, uh it makes sense that just return a property as if this were an actual named struct.

D

But I also know that there's people that that also have the same view as you, um including one of the people that wants this api, where they feel that returning a tuple here is wrong from a property um yeah. I mean my own view of why it feels wrong.

E

Right and depending on how much work is involved in accessing dependent, like our our rule for properties, is aside from possibly lazy, initialization they're supposed to just be a field access right and.

D

As far as I'm aware, this should largely fall into that category. Okay, but yawn and maoni would be the expert here on it. That's always going to be true, including across like mono, for example,.

E

All right um emo: do you want to weigh in on the property versus method for the tuple? I know you, your answer was be a method named destruct or pose or whatever, but.

I

I would just I would basically just say this type is effectively a tuple, and so you, just you just get to decompose deconstruct, I think, is the phrase.

C

E

All right, so um I and then I was gonna- suggest interrupt services, but apparently john suggested compiler services. So.

D

Right and then in particular the one changes it should be dispose not free, because we ended up landing on that and then just never updating the original proposal.

E

uh It should not be disposed unless it's high disposable and if it's disposable, it needs to be disposed that impotent. So it should be free.

D

Okay, fair enough you! If, if yawn, has significant pushback here, then then that will be raised with this being very special type. At.

G

All I mean is the intention to keep this consistent with gc handle.

D

Well, so that that's something that came up in the discussion of gc handle would would be. It would be incredibly useful for it to have disposed as well, and there was a there was a multi-comment discussion between jan and maoni on the ys, and why nots and things like that.

G

And do those all just apply here.

D

Yep, it was the it was mostly all the same.

D

G

The other thing is gc, handle is in interop services.

E

Which is why I was suggesting interop services, but apparently john doesn't want it in interop services, so he suggested moving it out.

E

I'm guessing this went with compiler services because that's where conditional weak table is.

E

I think that's where conditional weak table is like it's in a weird spot. No.

G

Yeah it's in compiler services, so that's probably why it was internally yeah. Do we have reasons why, if we're making this public that it should stay there to align with conditional weak table.

D

I think likely because it's, namely a special compiler oriented type and not necessarily an interrupt type whereas whereas gc handle is largely it's, it's really an interop type. It's so that you can interact with gc types from outside of net, whereas this is really let's do something special, that's realistically only visible to the runtime only possible via the runtime and it's compiler types.

E

Well, I mean I disagree with conditional weak table being associated with compilers, because I've used it in plenty of things and I've never written a compiler. Okay, that's not true script. Sharp was a compiler, um but I've.

G

In my weak delegate system, for example, which really has nothing to do with the compiler yeah.

D

Right but unsafe also has nothing to do with compilers, technically speaking, and it's it's there as well, yeah, true, like between compiler services and interop services, there's not really a clear definition of what goes where and maybe we should have shoved a bunch of it in just run time. Instead,.

E

I mean yeah runtime actually seems like a. I don't know what's in run time, but nothing.

E

uh I guess there's nothing in system.formats either, but.

E

uh No system runtime has apparently ambiguous implementation exception. Oh yes,.

G

E

Too gc settings gc, latency mode um yeah. I think runtime.

G

Yeah, I think, that's better. I guess to tell you the truth, but.

D

The only thing I really don't want is for this to like get significant pushback from yawn on anything such that it requires a secondary api review.

G

I mean the fact that gc stuff is already there. I mean that's really kind of what this is connected to right. Yeah.

A

G

Kinda, it's like it's a weak handle between dependent to target or is it a strong end.

E

uh It it's the weak handle, that's why it's powering weak table.

E

Right this is, I guess, confirming tanner. This is as long as target is not garbage. Collected dependent is not eligible for collection, but if target goes out of scope, dependent is allowed to be gcd right. So this is the.

E

Dear cash go ask for this, I guess but target isn't also isn't rooted by this object. Right right. I believe that's the case right. So it's I have this handle hey if the target hasn't been gc'd yet then give me the dependent, but you know basically that's a cache key and a large dictionary, and once people stop talking about the cache key, let the dictionary get reclaimed.

E

um That's the way that I've used conditional weak table. I think so. Okay,.

G

So it is about gc fish stuff again, because it's a dependent handle, so it feels decent to go with other gc stuff yeah.

E

Hey the thing that I think we have enough of an opinion on that, I can change the code here.

E

E

So a lot of what we have is a lot of not strong opinions on things.

D

Yeah it to me, it comes across as it basically looks good. There is some open questions where yon should weigh in and say, yay or nay, and that basically influence and we're good with either yay or nay, but yawn's the ultimate decider there of what is correct because he's the principal architect and so we'll basically approve it. We'll tag you on john will say which route we should go on each point and then we'll implement.

E

It yeah I mean. Certainly my recommendation is all of these become methods. Nothing is a property, I'm sorry, it's allocated it's fine um and.

E

Yeah, but I guess whatever yawn's happy with I'll, shrug it aside from renaming free to dispose that one I'll uh continue opposing unless you make destructive potent safe, which I don't think anyone wants to do.

G

Just in my head to make sure I have it right like for the target independent naming like internally in the code, we actually named them primary secondary.

D

Right and in the thread below the the proposal here, it was discussed at depth on whether primary secondary was secondary, was the correct name or target dependent, and it was ultimately determined that target dependent is much clearer um and then the the alternative of f fmrl is not correct for the given usage here.

D

G

Again, the I make one of these- and it says as long as this target is alive- keep dependent alive.

D

That's the high level overview. Yes, okay,.

G

Okay, at least, if I can understand it from the name.

E

Sounds good right, so it makes a gc arrow from target to dependent, but does not make an arrow to target.

E

um So once all the arrows to target disappear, dependent may become gc eligible depends on whether there are other arrows pointing at dependent all right should I call this approvedemo.

I

I probably would.

G

I

G

Other ones could be done through email if we, if we really wanted to right like if it was, should it be methods or.

E

E

Boom, all right so um apologies to anyone on the stream uh I already apologized in the chat. But apparently when I pushed the start stream button, computers got in the way and decided that it was just going to create a placeholder stream and not actually stream. So in the beginning, where I showed off reload to restore this page, the new api review public calendar based on a public suggestion, uh huzzah api review.net schedule and since it's new I'll, just confirm emo, we don't have a meeting on thursday.

I

So I've not set up anything yet for thursday, so I thought the idea is that we go back to once a week and I think, given the backlog, that seems not unreasonable unless people feel like it is.

E

It's fine with me. I think we're.

E

Like the two things.

D

The things we didn't get to.

E

Here are like they're not going to get in today and there's not really a reason to get thursday versus tuesday. So I think we're good for seeing people.

E

On the 22nd at 10 a.m, redmond time as always and following my recent formula, I now observe that we are over our schedule or over our allotted time, and I declare this meeting adjourned.

G