►
From YouTube: 2022-03-16 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
It's
not
that
late
because
there's
we
do
not
have
this
one
hour.
Time
shift
because.
D
B
E
Hi
there,
just
let's
give
those
one
or
two
extra
minutes.
Chris
is
not
joining
us
today
and
next
week
he
kind
of
got
a
last
minute
vacation.
So
two
weeks
without
chris
here.
B
E
E
Basically,
I'm
kind
of
ensuring
that
they
are
out
running
kind
of
documenting
and
making
easy
for
people
that
come
to
the
repo
to
be
able
to
run
them
and
in
the
process
I'm
removing
the
poc
stuff,
because
it's
not
a
poc
anymore.
It's
our
way
forward
and
kind
of
also
adding
the
readme
with
the
explanations.
E
I
think
there
is
more
stuff
that
we
can
do
here,
but
I
think
for
this
pr.
I
want
to
kind
of
stop
here.
I
think
we
can
unify
also
the
server
application,
because,
right
now
we
have
two.
We
have
this
one
that
is
kind
of
the
standard
server
application
and
we
have
one
to
demonstrate
the
startup
hook.
I
think
it
could
be
the
same
app
we
just
need
to
configure,
but
I
will
do
that
separate.
I
also
want
to
rename
the
project,
but
also
planning
to
do
that
separately.
E
But,
basically
is
that
so
I
think
more
than
the
the
apps.
Please
take
a
look
at
the
readme.
If
you
have
to
look
just
at
one
thing.
Look
at
the
readme,
you
know
kind
of
it's
simple,
but
I
think
it's
the
main
thing
and,
as
I
said,
it's
kind
of
I
need
to
link
somewhere
in
developing
or
something
already
linking
to
some
docs,
but
I
think
should
be
for
people
that
want
to
kind
of
get
a
view
of
the
project.
E
Okay,
so
this
is
for
the
prs
that
we
have
oh
in
the
process.
I
discovered
a
new
issue,
let's
see
so
this
seems
to
be
a
regression
of
something
that
I
had
fixed
some
time
ago,
but
in
this
process
of
testing
the
sample
apps,
I
noticed
that
we
are
generating
every
10
seconds,
two
expanse
for
mongodb
instrumentation.
E
Cool
so
yeah
this
is
a
must
fix,
is
one
of
the
two
instrumentations
that
we
have.
This
needs
to
be
working,
and
they
strange
thing
they
strange
thing.
This
is
a
kind
of
side
effect.
If
you
keep
the
application
running,
your
trace
keeps
growing
depending
it
doesn't
lose
the
context
in
the.
B
Same
sense,
there's
one
thing
that
I
should
I
think
we
should
consider.
Mongodb
has
published
an
extension
for
open,
telemetry
and
there's
a
one,
zero,
zero
release.
I
think
that
it's
that
we
should
use
it
instead.
E
So
they
they
released
the
hooks
or
the
instrumentation
itself.
E
D
Sorry
I
was
just
saying
that
if
robert
can
open
the
issues.
E
B
E
See
if
we
can
incorporate
and
then
do
that
a
related
thing
that
this
reminds
me
is
that
since
it
passed
the
tests
and
upstream
has
a
very
good
thing
using
the
verify
stuff
in
tests.
This
is
something
that
we
should
look
forward
in
the
future.
You
know
because
avoids
this
kind
of
thing.
Oh
there
is,
I
actually
expand,
but
then
it
kind
of
oh
doesn't
match
anything,
and
then
we
break
you
know.
E
So
we
don't
need
to
do
the
verify
stuff
for
beta,
but
it's
a
really
nice
thing
to
have
on
the
repo.
So
in
the
future
you
should
consider
that
okay
and
that
does
it
for
new
issues.
E
So
this
one
that
we
talked
about
oops,
I
clicked
the
wrong
link.
B
We
are
missing
four
issues.
Could
you
go
back
to
the
list?
You
have
clicked
the
third
hyperlink,
not
the
second
one.
Could
you
go
back
to
the
document?
Please.
F
E
E
Okay,
so
the
project
board
again,
let's
go
there.
E
So
we
have
this
stuff
in
progress.
Isn't
this
done
for
the
time
being,
or
we
still
have
to
add
options?
I
think
we
may
want
to
consider
a
configuration
option
to
disable
this.
E
Okay,
so
we
keep
it
in
progress
and
we
can
perhaps
take
parts
of
it
and
and
do
it
later.
E
So
these
are
the
two
that
I'm
doing
erasmus
and
robert.
Do
you
have
any
appetite
for
these
committed
issues.
D
Yeah,
the
one
is
on
the
list
on
the
today's
topic
and
the
second
one
is
just
in
case
open.
If
there
is
something
else.
E
Okay
yeah,
I
I
open
one
today
and
we
also
can
trigger,
runs
right.
You
probably
don't
have
the
rights
I
I'll
trigger
some
runs
today.
So
if
there
is
anything
we
I
I
will
add
to
the
issue.
E
B
E
Yeah,
but
I
I
I
know
what
you're
talking
about
when
you
you
you,
you
talk
about
a
test
that
kind
of
tests
everything
at
once,
but
on
the
other
hand,
we
need
something
yeah.
B
E
Be
a
burden
yeah,
so
this
is
something
that
chris
mentioned.
I
think
last
week,
or
he
mentioned
he
was.
B
E
So
I
think
the
the
main
thing
is
that,
because
of
the
integration,
apps
kind
of
the
tests
typically
depend
on
docker
and
this
kind
of
thing
it's
not
only
the
app
but
and
I
think
to
really
do
a
really
really
nice
work
you'll
be
after
beta,
but
we
should
consider
kind
of
not
only
have
this
infrastructure,
but
also
things
like
the
infrastructure
takes
care
assumes
that
integration
tests
has
a
docker,
you
know
kind
of,
and
it
starts
stops,
does
all
that
stuff
and
perhaps
for
ashley.
E
E
All
right-
and
I
think
we,
the
only
new
issue-
was
this
one
was
already
addressed
this.
E
All
right,
so,
I
think
the
the
main
issue
that
I
I
I
think
everyone
wants
to
kind
of
discuss
is.
I
think
erasmus
opened
this
good
issue
some
time
ago
and
got
up
at
least
people
from
the
run
time
to
discuss,
and
they
are
basically
back
to
their
recommendation.
That
was
the
kind
of
plan
that
we
had
initially
with
greg
and
raj
also
mentioned
about
having
a
rapper
that
takes
care
of
the
multiple
versions.
E
B
B
B
E
E
In
the
end,
the
biggest
problem
for
us
is
that
we
can't
leverage
the
sdk.
You
know
that's
the
biggest
problem.
If
it
wasn't
active,
it
wasn't
part
of
their
own
time
and
underlying
the
sdk.
If
you
are
writing
everything
on
our
own,
then
it's
fine,
you
know,
but
the
idea
is
that
we
want
to
leverage
the
work
that
happens
on
the
sdk.
You
know
and
the
contrib
so
to
leverage
that
we
need
to
to
have
a
way
to
do
that
and
we
need
to
be
performant
right.
E
I
don't
want
to
be
over
the
top
performance
kind
of
say
that
any
penalty
in
performance
is
a
blocker.
I
don't
want
to
be
that,
but
on
the
other
hand,
I
want
to
be
careful
kind
of
okay.
Let's
try
to
make
this
work,
but
what's
the
cost
you
know,
so
I
think
I'm
I'm.
I
think
we
should
take
that
path.
That's
there
and
we
rasmus
already
mentioned
kind
of
in
the
late.
E
This
discussion
that
we
are
not
that
concerned
with
ahead
of
time,
compilation
at
least
for
now,
because
it's
not
the
typical
for
the
applications
that
we
monitor
is
not
the
typical
scenario.
Our
typical
scenario
server,
and
perhaps
the
thing
that
was
discussed
in
the
past.
We
know
that
we
can
manipulate
the
configuration
files
and
get
those
to
work.
E
But,
as
far
as
I
know,
there
is
no
support
to
do
that.
Manipulation.
You
know.
Okay,
there
are
json
files,
this
kind
of
thing,
but
what
we
would
like
to
have
is
kind
of
some
support
of
the
runtime
people.net
runtime,
at
least
to
kind
of
guide
us
that
we
are
following
the
right
things
about
those
files
and
perhaps
apis,
to
manipulate
those
files.
E
You
know
if
we,
if
we
are
kind
of
thinking,
dot-net
core
and-
and
I
think
this
is
the
case-
that
we
really
care
about
this.net
core
first,
because
we
have
binding
redirects
in
the
dotnet
framework
and
the
dot
framework
is
in
the
past.
You
know
a
lot
of
people
are
still
using,
but
if
you
think
long
term
is
the
past,
so
for
net
core,
it's
equivalent
of
adding
a
new
get
package
after
built.
E
You
know
if
you
have
the
configuration
files,
if
we
could
do
that
and
they
guide
us
to
that
process.
I
think
is
a
good
outcome
for
us.
So
I'm
kind
of
thinking
jumping
on
the
thread
and
ask
for
that.
C
Yeah
just
give
me
like,
or
maybe
the
we
will
touch
on
that,
like
updating
this
thread,
because
tomorrow
I
have
a
meeting
with
the
dot
net
folks,
but
this
message
is
coming
from
a
very
high
level,
the
guy
who
is
responding.
C
It
is
coming
from
a
high
level,
so
we
may
not
have
other
ways,
but
still
I
want
to
check
because
the
other
like
solution
which
I
proposed
earlier,
I
worked
with
the
developers
of
the
diagnostic
source
itself
and
considering
all
the
puff
factors
and
everything
we
came
up
with
that
approach.
There
were
too
many
things
we
discussed
and
this
turned
out
to
be
the
better
approach,
because
it
does
not
impact
the
puff
a
lot,
but
there
is
a
little
memory
over
her
head.
C
So
the
reason
is
we
create
a
span
or
an
activity.
We
clone
that
for
the
higher
version,
so
that
that
was
the
one.
So
I
still
need
to
get
a
clarity,
because
I
don't
know
everyone
is
in
the
like.
It
has
the
same
understanding
internally
here
so
just
want
to
check
and
understand.
If
there
is
an
idea
like
for
us,
we
may
not
need
to
proceed.
C
Do
anything
over
here
if
there
is
nothing,
that's
when
whatever
you
said
is
right,
we
may
need
to
have
someone
from
dotnet
joining
us
regularly
and
at
least
reviewing
our
pr
to
give
us
like
feedback
on
whether
we
head
in
the
right
direction
or
not.
D
B
Please
correct
me:
if
my
comment
is
wrong:
anyone
the
same
problem
with
diagnostic
source
is
also
for
the
dotted
sdk
so,
for
example,
a
conflict
of
versions
when
the
instrumented
app,
I
don't
know,
uses
older
or
newer
version
of
sdk
than
the
auto
instrumentation
library,
as
well
as
grpc.
All
things
that
we
depend
on.
Basically,
no
no,
but.
E
The
thing
is,
the
sdk
requires
people
building
the
application.
When
you
build
the
application,
the
new
get
package
resolution
version
for
net
core
is
going
to
pick
up
all
those
dependencies.
It's
going
to
figure
out
and
it's
going
to
bring
the
latest
one.
E
The
problem
is
that
if
you
already
get
the
application,
so
it's
not
the
sdk,
then
we
have
that
problem,
because
when
we
try
to
load
then
we
have
the
issue
so
think,
like.
D
E
That's
true,
but
but
at
least
on
that
case,
if
the
person
has
a
old
version,
but
they
are
going
to
build,
we
can
tell
them
what
version
they
need
to
use.
The
problem
becomes
with.
I
already
built
the
devops
scenario.
You
know
the
application
is
a
real
build,
and
now
I
want
to
update
the
new
get
dependence
of
your
application.
E
Yeah,
no,
I
wanna.
I
wanna
up
data
your
new
get
dependencies
after
build,
you
know.
So
that's
the
challenge.
You
know.
C
Yeah,
so
another
thing
is
like
the
robot
like
like
you're,
asking
right,
because
if
customer
brings
a
3.1
app,
so
diagnostic
source
is
a
part
of
the
framework
itself,
even
he
does
not
bring
it.
We
are
going
to
run
into
an
issue.
So
that's
what
we
are
trying
to
like
solve
here.
This
is
a
secondary
issue
like
what
we
are
discussing,
that.
A
C
Like
our
additional
dependencies
and
other
things
should
take
care
of
it
because
in
3.1,
if
if
they
don't
specify
it's
going
to
get
the
diagnostic
source
by
default
from
the
3.1
framework,
but
with
the
like
introduce
be
having
a
runtime
store
and
also
like
additional
depths,
unless
he
has
a
like
application
level
dependency,
we
should
auto
upgrade
him
and
he
should
get
our
library.
So
in
those
case
we
can
use
an
additional
tabs.
E
Yeah
additional
depth
in
the
case
that
there
is
no
conflict
right
or
okay.
There
is
that
problem
that
you
point
at
that's
the
behavior
of
their
runtime.
If
we
ask
it
for
a
version
later
then
they're
on
time,
their
own
time
is
still
gonna
load.
The
old
right.
C
Yeah,
that
is
in
case
of
only
in
case
of
like
diagnostic
source,
because
that
library
is
a
part
of
the
framework.
That's
where
the
we
run
into
a
problem.
We
have
the
same
issue
with
the
logging,
also
when
we
go
and
like
we
haven't
touched
that
yet,
but
the
good
my
proposal
would
be
to
do
the
like
the
trace
and
metrics
first,
because
we
are
going
to
like
use
the
same
library,
the
diagnostic
source.
So
we
don't
need
to
worry
much
about
that.
C
So
we
can
finish
off
that
and
then
move
on
if
in
case,
if
we
plan
to
do
it
that
way,
but
it
will
be
more
appropriate
to
take
this
discussion
next
week.
The
only
reason
is
like
I
don't
know
like
if
they
have
some
other
plan
I'll
get
to
know
tomorrow.
If
not,
this
is
the
whatever
they
are
discussing
here.
This
is
the
direction
and
we
need
to
like
just
have
an
issue
which
I
have
in
our
repo
link
there
and
ask
whether
is
this
a
right
approach.
E
Yeah,
so
let's
do
just
to
be
sure
that
we
are
doing
the
this
follow-up
in
the
right
path.
Let
me
re
repeat
here:
I'm
gonna
add
some
comments
and
you
guys
also
feel
free
there
to
add
comments,
but
I
think
we
need
to
call
attention
this.
What
I
plan
to
comment,
the
limitation
that
we
see
regarding
the
sdk
I
I
actually
perhaps
there
is
a
solution.
I
remember
noah
mentioned
this
for
us
long
long
time
ago.
E
This
kind
of
version
wrapper,
but
I
didn't
understand
how
we
are
going
to
solve
this,
for
libraries
like
the
sdk
so
I'll
mention
that
and
why
we
are
interested
in
having
some
solution
for
this,
and
there
are
the
second
important
thing
is
that
a
solution
for
us
that,
okay,
I
have
this
application,
that's
a
red
built,
and
now
I
can
update
the
new
get
dependence.
E
It
risks
baking.
The
app
but
for
us
is
an
acceptable
risk.
You
know
because
if,
if
it
breaks
the
app
disable
run,
the
normal
app
you
know
kind
of
there
is
no
kind
of
other
cost
than
that.
The
alternative
is
not
as
not
not
running
for
that
application.
So
we
are
in
the
same
place
if
they
need
to
disable,
because
there
is
a
compatibility
issue.
We
are
back
in
the
place
that
we
are
right
now,
so
I
think,
for
us
is
acceptable,
so.
C
So
this
is
the
design
we
have
it,
at
least
for
your
thought
process
like
now
here.
So
if
customer
brings
some
sdk,
which
is
holder-
and
we
try
to
like
if
auto
instrumentation
is
trying
to
bring
a
sdk
which
is
higher
version
than
that,
we
have
a
conflict
and
we
might
the
older
might
win
that
because
he
has
it
a
part
of
his
application
yeah.
So
the
solution,
what
we
have
is
we
have
the
il
repack
version
of
the
sdk.
C
So
what
we
do
is
we
load
the
il
repack,
the
complete.
It
will
be
a
single
library
of
the
complete
sdk,
we
load
it
and
once
we
load
it
when
we
load
it
itself,
we
take
the
control,
we
disable
all
the
telemetry
that
is
coming
from
the
customers
like
customer
bringing
sdk
and
we
enable
only
telemetry
from
the
auto
instrumentation
sdk.
C
So
that's
a
solution.
We
have
it
now
to
like
overcome
this
issue.
Whatever
we
have
discussed,
it
may
be
sdk
or
the
other
instrumentation
library.
That's
the
current
implementation
that
works
for
us
now.
E
Okay,
but
just
but
but
just
to
kind
of
the
next
steps
here,
I'm
gonna
add
these
comments
and
about
these
two
things
that
I
mentioned
so
tomorrow.
People
can
read
before
perhaps
you're
a
meeting
with
them
and
then
we
we
follow
up
from
there
and,
as
I
said,
I'm
saying
I'm
gonna
write
because
I
put
this
as
a
task,
but
anyone
of
course
feel
free
to
jump
there.
You
know.
C
These
are
the
realities,
because
we,
these
are
things
missing.
I
feel
it's
better
to
have
that
documented
there
for
us.
So
anyone
takes
a
look
we'll
understand.
What's
a
real
issue
for
us
in
using
this.
E
B
C
So
I
we
are
using
the
startup
hook
already,
the
implementation
is
already
live.
Actually
I
haven't
seen
any
issues
with
it.
The
one
problem
might
happen.
For
example,
if
you
give
this
solution
and
set
an
environment
variable
for
the
whole
machine,
any
dotnet
exes
that
is
running
on
that
machine
is
going
to
pick
this
up
and
try
to
load
it.
So
that's
the
only
drawback
I
could
see
so.
C
If
you're
trying
to
use
a
startup
hook,
you
need
to
confirm
it
to
your
process,
not
to
the
whole
environment,
because
any
in
windows,
if
we
take
any
executable,
most
of
them,
will
be
based
on
the
dot
net
code.
Nowadays,.
B
B
C
Very
simple:
actually,
the
startup
hook
cannot
have
any
package
on
its
own.
It
should
depend
on
the
package
from
the
application
so
yeah.
It
should
have
a
very
small
code
within
it
just
to
bootstrap
it,
and
you
should
not
be
doing
a
very
big
logic
inside
a
startup.
That
is
never
a
recommended
thing.
Let's
see.
E
One
thing
I
I
already
mentioned
this,
but
I
would
love
to
in
the
future
to
look
at
the
possibility
of
unifying
because
right
now
we
have
a
startup
hook
and
we
can
still
attach
as
a
profiler.
E
So
I
would
love
to
see
if,
instead,
we
can
kind
of
rely
only
on
the
startup
hook,
because
I
think
it's
simpler
to
configure
and
then
from
the
startup
hook.
We
load
the
profiler.
E
I
know
that
there
is
a
native
api
for
doing
that,
but
we
can
even
use
the
perfect
view
nuget
package
that
has
managed
code
already
doing
that
to
load
the
profiler
from
managed
code.
So
we
could
load
the
profiler
from
this
up
hook
and
we
could
do
very,
very
interesting
things
interesting
things
now,
but
things
that
kind
of
tailor
better.
E
What
you
are
doing
in
the
sense
that
let's
say
there
is
no
il
instrumentation
that
the
user
selected,
because
right
now
we
have
the
user
has
to
be
spliced
about
the
instrumentations
that
they
want
to
add.
So
if
there
is
no
il
instrumentation,
this
code
on
the
startup
could
kind
of
go
and
kind
of
hey.
There
is
no
need
to
add
the
profiler.
You
know.
E
E
So
I
kind
of
would
like
to
rely
more
on
that
even
for
this
case
about
the
whole
machine,
you
can
have
something
like
okay,
it's
configured
for
the
whole
machine.
You
start
the
startup
hook,
but
then
there
is
no
hotel
setting
enabled
or
something
you
do
nothing
and
go
ahead.
You
know
but
but
but
these
are
ideas
for
the
future.
B
So
I
just
opened
the
documentation
for
the
startup
hook
so
like
the
use
case
that
even
is
proposed
is
to
set
up
tracing
and
telemetry
injection,
as
the
first
example
here
and
the
trouble
which
we
have
is
the
caveat.
This
is
how
I
should
provide
like
I'm,
not
sure
how
should
I,
how
how
we,
pronounce
this
caveat,.
C
B
Okay,
so
no
dependency
resolution
for
no
app
assemblies,
no
configuration
for
the
position
shared
by
hook.
So
these
are
our
problems
right
this
one
and
this
one.
C
Yeah
yeah,
so
the
one
more
thing
on
what
paulo
said
we
can
extend.
Instead
of
keep
on
extending
our
startup,
we
can
have
an
one
more
startup
hook,
yeah,
so
it
can
execute
an
order.
So
that
would
be
a
even
nice
idea
if
you
are
planning
to
do
it
in
that
way.
Instead
of
making
it
heavy
on
a
need
basis
in
that
environment
variable
provide
two
like
startup
lightroom.
E
Okay,
so
going
to
the
issue
about
activity
current
that
I
want
to
kind
of
brainstorm
with
you
guys-
and
this
is
something
that
perhaps
we
also
have
to
interact
with
the
dot
net
runtime
about
it.
So,
typically,
when
you
have
anything,
that's
a
context
that
you
want
to
associate
to
the
async
and
thread
stuff.
You
have
a
sync
local,
so
that
was
what
was
on
the
code
from
from
upstream
and
it's
the
typical
way
that
people
do
that.
E
So,
for
instance,
the
activity
current
represents
that
it's
async
local.
So
we
are
a
prototype
working
on
some
profiling
code,
so
you
we
want
to
associate
stacks
to
a
giving
spam
activity.
E
So
what
we
did
was
when
we
create
the
async
local
that
tracks
the
spam
contacts.
E
We
used
event
that
you
can
do
when
you
create
async
local.
So
we
implement
a
delegate
to
receive
the
call
for
that
event
and
when
that
event
happens,
we
call
the
profiling
update,
so
that
works
fine.
We
know
that
there
is
a
penalty
performance
on
that,
but
it
works
fine.
We
can
update
and
we
can
relate
one
span
to
one
stack
that
we
collected.
We
know
which
span
was
the
context
of
the
stack,
but
thinking
about
the
future
we
are
gonna.
Have
we
may
wanna?
E
E
E
I
don't
know
if
perhaps
the
native
already
has
some
way
to
track
the
current
activity
that
then
the
profilers
could
leverage
that
instead,
I
think
this
is
possible
because
activity
exists
for
a
long
time
and
a
lot
of
things
have
these
achieved
contacts.
If
you
see
the
old
events
that
now
are
on
event
pipe,
you
have
a
brazilian
things
that
have
the
activity
contacts.
E
So
I
don't
know
if
it's
this
something
like
that,
but
at
first
I
I
didn't
search
for
a
long.
I
was
just
thinking
about
this
and
when
I
had
time
I
searched
like
for
10
minutes,
and
I
I
didn't
find
it,
but
perhaps
this
is
another
way,
but
before
I
start
to
bring
this
to
the
dot
net
runtime,
I
would
like
to
see
if
you
guys
had
any
ideas
or
considerations
about
this
kind
of
problem.
E
I
first
question
is:
did
you
guys
understand
the
problem?
I.
B
E
Basically,
basically
think
is
like
this:
I
want
to
collect
a
stack
sample
on
the
profiler.
This
nature
is
called.
Oh
and
now
I
remember
third
option
so
when
I'm
collecting
that
stack
that
stack
you
be
in
the
context
of
to
be
an
activity
right.
So
the
question
is
how
the
native
code
is
gonna
know,
which
activity
is
that.
E
E
You
update,
I
call
back
the
native
code
and
tell
hey
this
thread
now.
This
managed
thread
is
now
under
this
context
and
whatever
the
contacts
change,
I
make
a
quick
call
to
the
native
code
and
the
native
code
updates
it
stable
when
it
collects
the
stack.
It
knows
exactly
because
it's
to
spend
also
the
the
runtime.
You
know
it's
suspended
red.
So
that's
the
thing.
So
it
knows
exactly.
E
The
the
thing
goes
when
you
try
to
move
these
two
open
telemetry
that
depends
on
activity
active
dot.
Current
is
in
a
sync
local,
the
same
way
that
we
use,
but
the
constructor
is
not
supposed.
So
you
can't
subscribe
to
the
same
callback
that
I'm
using
you
know.
E
So
the
this
callback
is
only
on
the
constructor
of
their
sync
local,
that
you
can
pass
that
so
as
of
right
now,
if
I
wanted
to
use
similar
code
for
active
current,
I
can't
no.
There
is
no
way
so
I
now
stop
here
before
I
talk
about
the
possible
alternatives.
E
But
so
the
things
that
I
thought-
okay,
perhaps
a
sync
current-
could
wrap
something
that
exposes
a
way
to
subscribe.
To
that
same
event,.
B
E
If
you
see
the
constructor
of
async
local,
you
can
pass
a
on
value
change
it
handler
that's
the
callback
as
a
delegate.
That
is
call
it
back.
You
know,
so
that's
enough
for
that
implementation
that
I
talked
before.
But,
as
I
said,
you
have
active
dot
current.
You
don't
see
the
creation
of
the
async
local,
so
we
already
missed
the
opportunity
of
having
that.
So
this.
E
So
they
they
could
create
a
type
that
would
be
a
change
on
their
own
time.
That
kind
of
creates
with
the
handler
and
also
they
could
expose
a
new
property
that
actually,
you
can
add
delegates
there
to
to
get
that.
So
this
is
one
thing,
requires
api
change
on
the
runtime.
E
The
second
thing
is
that
I
know
that
there
is
a
bunch.
Sorry,
there
is
a
bunch
of
active
context
attached
to
a
bunch
of
events,
so
there
is
some
way
to
track
that
right.
I
don't
know
if
the
profiler
could
access
that
information.
E
You
know
that's
what
is
used
for
events,
but
I
don't
know
if
the
profiler
could
ask
that
if
us
access
that
information,
I
searched
that
kind
of
very
10
15
minutes
on
the
code
and
things
I
didn't
find
anything,
but
it
doesn't
mean
that
doesn't
exist.
It
just
means
that
I
didn't
find
it.
The
third
alternative
that
I
see
is
a
bit
more.
Intricate
is
kind
of
okay,
async
local
is
based
on
a
thread
static,
so
the
profiler
could,
in
theory,
inspect
the
thread
static
for
those
and
get
that
information.
E
I
would
love
to
avoid
to
do
that,
but
perhaps
is
already
the
the
other
alternative,
but
I'm
thinking
in
bringing
this
up
with
the
dot
network
on
time
too,
because
aldo
is
not
something
that
we
need
now
in
the
short
run
for
open
telemetry.
E
If
we
need
something
on
their
own
time,
I
would
love
to
get
on.net
seven
already,
because
even
if
I'm
working
in
the
future
then
at
least
in
dot
net
seven,
we
already
could
use
this
feature.
You
know
so.
A
So
when
it's
going
to
go
execute
that
the
callback-
whichever
I'm
pretty
sure,
that's
in
the
stutter
for
the
current
figure
out,
if
we
can
rewrite
that
method,
to
do
a
p,
invoke
and
see
the
profiler.
E
Yeah,
no,
so
I
this
is
what
I
did
in
our
code,
but
you
are
you,
but
what
you
you
you
get
me
thinking
is
two
things.
Perhaps
that
could
be
part
of
the
update
of
the
async
local
of
the
of
the
active
directly
even
without
us,
subscribing
to
the
event,
and
they
could
update
some
information
that
the
profiler
has
available
easily
available.
You
know
and
another
thing
that.
E
Yeah,
no,
I
I
I
I
I
I
think
that
we
end
up
kind
of
in
a
similar
idea.
No,
no!
But
but
that's
why
I'm
bringing
this
this
this
conversation
here,
because
I
want
to
hear
what
come
up
to
people
and,
of
course
you
guys
just
heard
about
the
problem
and
maybe
the
idea
pop
up
in
6
12
24
hours
later,
you
know,
so
I
just
want
to
bring
it
up.
As
I
said,
I'm
I'm
thinking
bring
it
up
to
that.net
runtime.
E
When
I
do,
I,
of
course
you
you
share
with
the
sig,
so
you
guys
can
chime
in,
but
I
think
this
is
perhaps
for
profiling
that
collects
stacks
and
wants
to
correlate
to
activity
is
kind
of
a
general
problem.
You
know.
E
So,
as
I
said,
I
I
didn't
expect
kind
of
major
breakthroughs
here,
just
kind
of
trying
to
brainstorm
and
and
see
what
you
guys
come
up,
so
we
can
move
ahead
on
this.
So
it's
just
the
first
step,
as
I
said
I
think,
perhaps
later
this
week
or
beginning
of
next
week,
I
opened
ieshon.net
runtime
miui.
If
you
guys
have
something,
let's
discuss
when
it's
lag
or
github
or
whatever
it
works
better.