►
Description
Async I/O has forever been a hot topic of discussion in Rust, but over the past year we’ve seen some significant advances in this domain with the futures crate an the Tokio project. We’ll start off by taking a look at where we are today with the async I/O ecosystem in Rust, highlighting a number of the features we’ve added in both the libraries and the language over the past year. We’ll then take a deep dive into Tokio itself, seeing how it capitalizes on some of Rust’s greatest strengths by going Back to Futures and gets our DeLorean up to 88mph.
About Alex Crichton:
Alex is a member of the Rust Core Team who has worked at Mozilla on Rust for the past four years. He is also a member of the Tokio Core Team, one of the primary authors of Cargo, helps maintain the standard library, and likes to ensure that engine of Rust never stops.
A
A
So
I'm
not
sure
it
was
actually
what
we
talked
about,
but
I
imagine
it
was
something
like
his
grand
secret
vision
of
like
taking
over
the
Ross
project
and
speeding,
apps
coming
a
I
singularity,
but
I,
don't
think
that's
the
kind
of
futures
he
is
going
to
talk
about
now
anyway.
So
it's
it's
movie,
your
movie
related
what
he
is
going
to
talk
about.
So,
of
course,
to
ask
him
what
is
the
best
indie
time
travel
movie
and
why
is
it
primer.
B
B
Okay,
sorry
I
should
say
non
American
friendly,
but
any
case
my
name
is
Alex
I'm
member
of
the
core
team
I've
been
working
on
rest
for
about
four
years
out
of
Mozilla
now
and
today,
I'd
like
to
like
tell
you
talk
to
you
about
Tokyo
and
asynchronous
I/o
framework
and
when
I
say
88
miles
per
hour.
What
I'm,
actually
referring
to
is
this
movie
called
back
to
the
future.
B
So
when
I
talk
about
I
want
to
talk
about
back
to
the
future,
I
mean
I'm
using
this
movie
because
it
has
the
word
future
in
it,
but
also
it
implies
this
insane
level
of
speed.
And
so,
when
I
talk
about
this,
what
I
mean
is
that
Tokyo
itself
is
an
insanely,
fast,
asynchronous
I/o
framework,
so
this
is
kind
of
the
canonical
chart
that
we
like
to
show
which
actually
introduced
Tokyo
and
futures
to
the
rest
community.
We're
on
this
far
left
on
the
far
left.
B
You
have
this
very
tall
graph,
which
is
the
rust
thing
showing
that
we
have
this
insanely
high
request
per
second,
even
compared
to
a
bunch
of
other
frameworks,
and
so
almost
people
tend
to
have.
A
reaction
looks
like
this
Marty
McFly
and
Doc
I'm
gonna
I
I
will
tone
back
the
back
to
the
future
references
eventually,
but
not
yet
so
to
explain
this.
B
We
typically
say
that
rust
has
zero
cost
futures,
that's
kind
of
the
foundation
by
which
all
of
this
is
built,
the
zero
cost
future
aspects,
but,
while
you're
hearing
about
this
you're
like
wait,
hang
on
I'd
like
you
to
explain
a
little
bit
more
before
you
say
that
we're
gonna
say
all,
but
mio
is
low
level.
You
have
this
meal
library.
It's
great.
Does
all
this
a
society
like
great?
What's
me,
oh
well,
we
also
have
traits
it's
a
future
of
a
tree.
You
can
do
whatever
you
want.
B
We
have
this
Tokyo
frame
layers
and
all
these
possible
entry
points
for
you
and
we
have
lightweight
tasks
that
are
kind
of
like
green
threading,
and
it
ends
up
feeling
a
little
bit
like
this.
When
we're
just
kind
of
shouting
all
this
at
you,
and
if
you
don't
recognize
this
I
would
highly
recommend
you
watch
the
talks
from
Russ
comp
in
2016.
It
was
excellent,
but
so
today
I
want
to
give
you
the
equivalent
of
a
sports
Almanac,
and
you
might
be
thinking.
That's
that's
insane.
B
What
are
you
talking
about
here,
but
back
to
the
future?
That's
right,
there's
actually
three
movies,
but
in
the
second
movie
the
plot
of
this
movie
was
that
the
evil
Biff
Biff
just
sounds
evil.
The
evil
Biff
takes
a
sports
Almanac
back
in
time,
so
I
think
his
dad
at
that
time
and
Gabe
King
gives
us
to
him
and
then
using
the
sports.
B
The
first
thing
you
reach
in
foreign
programming,
which
is
synchronous
I/o,
so
in
synchronous
I/o.
What
typically
do
is
you'll
have
a
TCP,
socket
and
you'll
say
I
want
to
read
some
data
off
of
this
into
this
buffer
and
then,
after
some
amount
of
time,
the
kernel
will
come
back
and
say:
alright,
you
got
4
bytes,
and
the
key
thing
here
is
that
you're
the
calling
context
this
current
thread
is
blocked.
B
It
can
do
nothing
else
until
this
call
returns,
so
it
can
do
nothing
useful,
while
you're
waiting
for
a
TCP,
read
or
kind
of
bytes
to
come
in
and
I
can
take
a
very
long
time.
Sometimes
you
could
have
some
connections
boarding
at
megabytes
per
second
other
connections,
weren't
them
running
at
megabits
or
kilobytes
per
second,
it's
it's
kind
of
very
variable
there.
So
the
defining
aspect
of
a
synced
IO
is
that
the
kernel
immediately
says
nope.
This
is
going
to
block.
So
all
of
these
operations
like
when
you
we
didn't
do
a
buffer.
B
The
colonel
will
immediately
tell
you
I
do
not
have
bites
you're
gonna
have
to
figure
out.
One
to
call
me
again
later
so
specifically
what's
happening
here
is
that
every
single
IO
operation
in
the
icing
or
cider
world
never
blocks
everything
immediately
returns
and
just
immediately
takes
no
time
at
all,
and
then
later
you
will
receive
a
batch
set
of
notification.
Saying
these
objects
are
ready
for
reading.
These
objects
are
ready
for
writing
kind
of
various
events
coming
out
of
the
colonel,
and
so
you
are
then
responsible
for
actually
dispatching
these
events.
B
You
have
to
then
say
all
right.
Well,
I
am
interpreting
these.
These
giant
lists
from
the
colonel
and
I'm
going
to
figure
out
where
all
that
goes.
What
that
ends
up
looking
like
is
actually
a
very
difficult
world
to
work
with
so
typically
you're
a
pretty
reasonable
person.
You
just
want
to
grab
the
contents
of
the
rustling
homepage
and
just
want
to
render
that
your
browser,
your
servo,
your
whatever,
but
as
a
result
of
this
question
or
results
of
this
requests,
the
only
thing
we
can
do
is
all
file.
B
Descriptor
five
is
ready
and
that's
not
actually
very
helpful.
We
can't
okay,
well,
I,
don't
really
know
what
file
descriptor
five
is
connected
to.
Where
does
the
TLS
in
there?
So
kind
of
this
ends
up
being
a
very
difficult
system
to
work
with
this
kind
of
asynchronous
I/o
world
is
very
unwieldy.
It's
not
composable
and
it's
very
difficult
to
get
right
and
so
to
solve
this
problem.
This
is
where
futures
come
into
play.
B
All
you
know
is
that
you
can
pull
out
a
particular
type
from
it
and
it's
just
happening
asynchronously
in
the
background,
and
the
other
key
thing
about
features
kind
of
like
with
object-oriented
programming
is
that
you
can
actually
start
composing
these
together.
So
you
can
say
once
this
feature
has
completed:
I
can
now
run
this
future
or
I
can
change
a
future
of
a
string
to
a
future
of
an
integer
by
just
parsing
it
and
kind
of
all
these
other
various
operations.
B
You
can
do
internally,
just
by
kind
of
creating
and
mapping
and
dealing
with
all
these
features
that
are
themselves
objects.
So
an
example
of
this
is
this
previous
example.
We
had
of
kind
of
grabbing
the
contents
of
the
rustling
homepage.
Well
now,
when
you
ask
this
instead
of
saying
fob
escape
the
five
is
ready,
you'll
get
this
response.
Oh
no,
all
right
here
is
a
future
of
a
vector
of
bytes,
and
this
internally
encapsulate
everything
necessary
to
actually
deal
with
this.
So,
for
example,
this
is
going
to
make
a
TCP
connection.
B
Well,
it's
first,
it's
gonna
resolve
rustling
door.
It's
gonna
make
a
TCP
connection
to
one
of
those
sites.
It's
gonna
negotiate
TLS,
it's
gonna,
parse
the
HTTP
protocol.
It's
gonna
deal
with
the
request
response.
All
of
that
is
encapsulated
in
just
this
one
future
and
you
don't
have
to
worry
about
any
of
the
internal
states.
So
kind
of
all
that
is
built
for
you
and
you
know,
there's
much.
There's
far.
Fewer
kind
of
correctness
worries
it's
much
easier
to
get
futures
programming
correct.
B
That
needs
to
deal
with
just
juggling
file
descriptors
around
all
around
the
place
and
to
give
you
another
example
of
what
I
mean
by
futures
and
some
examples
of
what
you
can
do
with
it.
This
is
a
small
example.
What
we're
gonna
spawn
off
some
work
so
we'll
stay
here.
We're
gonna
on
some
thread
pools
spawn
the
115
op
G
numbers,
some
asynchronous
computation,
and
the
key
thing
here
is
this
function
will
immediately
return
and
this
local
variable
result
is
going
to
be
a
proxy
for
the
actual
value
of
the
hundred
Fibonacci
number.
B
So
in
the
meantime
we
can
do
whatever
we
can
grab
some
coffee.
You
can
try
and
wake
up,
because
it's
a
little
early
in
the
morning.
We
can
then
come
out
and
say
all
right
eventually.
I
actually
need
the
value
of
this
feature,
so
you
can
wait
on
it.
You
can
wait
for
it
to
be
resolved
and
I'll
perform
some
synchronization
with
the
actual
thread
pool
itself,
and
then
eventually,
this
result
down
here
at
the
bottom
will
actually
be
the
hundredth
Fibonacci
number
and
you
have
this
resolved
value
of
the
future.
B
And
so
the
key
thing
here
is
that
is
asynchronous.
Whenever
you
have
a
future,
the
the
computation,
the
result
of
that
computation
is
somehow
being
computed
in
the
background
at
a
quote,
unquote
sense
and
you
can
do
other
work
in
the
meantime
as
a
result.
Now
so
moving
up
to
Tokyo
I
like
to
say
that
Tokyo
is
the
fusion
of
the
Meo
library
and
futures.
B
Now
you
don't
have
to
worry
so
much
about
what
actually
mio
particularly
is,
but
it
suffice
to
say
that
it's
cross-platform,
async,
IO
and
so
dealing
with
async
IO
is
actually
entirely
different
on
Linux
and
OS,
X
and
Windows,
and
dealing
with
all
of
these
details.
All
the
time
is
very,
very
difficult,
so
what
mio
is
doing
is
basically
just
giving
you
a
cross-platform
uniform
interface
to
asynchronous
I/o.
On
the
actual
system,
so
what
anyone
says
me?
B
Oh
all,
I
really
mean
is
that
non-blocking
I/o
if
things
return
immediately
and
then
there's
some
way
later
to
get
a
batch
set
of
notification
saying
this
is
everything
that
just
happens
and
then
features.
On
the
other
hand,
with
Tokyo
basically
just
mean
that
you
can
build
up
these
features
with
AI
objects
internally,
so
you
can
say,
I
can
build
up.
Tcp,
sockets
and
I
can
have
suspect.
It
can
be
part
of
the
logic
of
how
to
resolve
my
future.
So
Tokyo
is
essentially
futures
powered
by
IO.
B
B
We
just
have
a
stream
trait
for
many
many
values
coming
over
time.
You
can
think
of
this
as
an
asynchronous
iterator
just
items
with
very
long
pauses
between
them.
We
also
have
a
sink
where
streams
are
kind
of
given
items
were
given
to
you,
whereas
with
a
sink
you
push
items
in
there
and
then
we
also
have
a
bunch
of
in
memory.
We
have
kind
of
a
very
large
toolkit
around
dealing
with
features
today,
so
we
have
one-shot
channels
for
in-memory
computations,
like
that
Fibonacci
number
we
saw
earlier.
B
But
so
the
other
thing
I
wanted
to
talk
about
with
features
today
is
we
actually
do
have
async
await
syntax
and
some
of
you
who
are
familiar
with
JavaScript
or
C
sharp
or
Python
working
in
the
asynchronous
worlds.
There
you'll
remember
that
you'll
probably
know
that
this
kind
of
syntax
is
critical
for
white
for
writing
large
applications,
and
so
this
is
only
available
in
the
nightly
Channel.
Today.
B
It's
very
pretty
recent
at
this
point,
but
some
of
the
highlights
are
the
you
can
activate
this
by
having
this
async
attribute,
which
says
that
this
function
is
actually
going
to
return
a
future.
So,
despite
saying
the
return
value
as
a
result,
this
is
actually
going
to
construct
some
future
and
then
return
it.
Whenever
you
invoke
it,
you
can
then
use
the
weight
macro
to
say
I
like
to
actually
block
on
this
value
of
the
future.
So
this
is
a
hyper
asynchronous
client
which
gives
you
a
future
result,
but
this
will
actually
block
the
thread.
B
It's
just
going
to
block
the
future.
So
this
is
still
an
asynchronous
computation
and
it's
able
to
just
kind
of
write
code
in
a
very
synchronous,
looking
style
well
end
up
just
building
a
giant
asynchronous
feature
if
you've
worked
with
Combinator's
and
rust.
If
you
kind
of
work,
the
futures
before
you'll
notice,
that
early
returns
are
insanely
hard
and
they're
very
easy
to
do.
B
This
is
gonna
wait,
so
this
is
kind
of
a
great
feature
having
early
returns
about
okay's
or
errors
and
again
just
kind
of
adds
to
the
very
synchronous
feeling
of
code
kind
of
what
you
would
expect
from
normal
rust.
As
you
write
it
today
and
then.
Finally,
we
also
have
asynchronous
for
loops
where
we
have
this
stream
trait
to
kind
of
values
coming
out
over
time.
So
this
is
saying
that
the
the
actual
body
of
this
HTTP
request
is
taking
a
long
time
to
come
to
us.
So
what
kind
of
process
each
chunk?
B
And
then
this
is
all
just
building
up
one
giant
feature
externally
to
work
with
so
I.
Just
don't
talk
a
little
bit
about
where
Tokyo
is
today.
Tokyo
is
currently
split
up
into
a
few
crates.
I
won't
go
into
too
much
detail
about
these.
We
have
took
you
a
core
awesome,
higher-level,
proto
and
service,
but
if
you're
interested
in
kind
of
the
details
here,
I
highly
recommend
you
start
with
the
current
RFC
and
kind
of
reorganizing.
B
Some
of
these
crates
I
just
think
it's
number
three
now
I've
had
to
close
that
by
accident,
but
it's
spice
to
say
that
in
any
case
today
we
took
you
has
a
very
large
amount
of
iterations
with
other
objects
in
the
community.
So,
in
addition
to
the
networking
types
of
TCP
and
UDP
you'll
have
unix-like
that's
named
pipes
signals
protocols
such
as
HTTP
coming
soon,
we've
seen
more
and
more
protocols
more
and
more
I
of
primitives
getting
bound
and
took
you
everyday.
B
So
you
end
up
having
a
very
large
suite
of
objects
to
choose
from
kind
of
what
you
would
expect
out
of
an
event,
loop
library
and
also
we've
seen
Tokyo
deployed
with
great
success
to
a
lot
of
companies
so
far
and
we're
super
excited
to
see
where
everyone
takes
it
from
there.
Sorry,
that's
a
little
bit
about
Tokyo
and
futures.
So
it's
a
bit
of
an
introduction.
B
So
now
now
they're
kind
of
on
the
same
page
I
want
to
dive
a
little
bit
more
into
why
the
future
tree
is
so
fast
and
so
we're
gonna
get
to
this
concept
of
tasks
that
have
actually
mention
that
later.
But
specifically,
let's
start
out
by
writing
a
future.
Let's
define
a
future,
let's
start
from
let's
circumscribe.
B
So
the
first
thing
that
we
might
do
is
write
down
as
struts
so
we'll
say:
we'll
have
a
struct
of
a
future
with
some
type
that
it
can
resolve
to,
because
it's
generic
and
I
don't
have
some
sort
of
invitation
for
this,
but
right
off
the
bat
there's
already
a
first
problem.
The
fact
that
this
is
a
struct.
This
means
that
there
is
one
implementation
of
the
future
that
we're
going
to
be
giving
you,
but
that
actually
might
not
always
be
correct.
B
That
could
be
a
thread
safe
future
and
you
may
not
want
to
pay
for
that
level
of
thread
safety.
It
could
be
an
entree,
say
future
and
you
want
that
level
of
thread
safety.
So
this
ends
up
being
very
inflexible
where
you,
by
having
only
one
definition,
we
can't
necessarily
cater
to
everyone's
needs
but
turns
out
rust,
does
have
a
feature
for
this
called
trace
so
traits
allow
you
to
have
the
most
specialized
implementation
for
a
future
that
you
possibly
need.
So
your
case
of.
B
If
you
need
thread
safe,
you
can
use
a
thread
safe
future.
If
you
don't
need
thread
safe,
you
can
use
a
non
for
a
safe
future
and
it
kind
of
they
can
still
interoperate
together,
because
they're
still
implementing
the
same
fundamental
tree
I'm
this
we
have
an
associated
item
what's
actually
coming
out,
but
another
problem
is:
we
have
to
actually
fill
the
soon.
B
We
need
to
have
some
sort
of
implementation
here,
and
so,
as
I
was
saying
earlier,
a
feature
is
a
sentinel
for
a
value
which
is
going
to
become
available
at
some
point
in
time,
and
so,
when
we
think
about
this,
it's
kind
of
a
future
is
an
asynchronous
computation.
Eventually,
it's
going
to
be
run
adventure
it's
going
to
be
completed,
so
why
not?
Let's
have
some
sort
of
callback.
B
Let's
say
that
when
this
feature
is
resolved
when
this
feature
finishes
completing
itself,
it's
going
to
invoke
this
callback
with
the
actual
value,
and
that
way
you
can
then
do
further
processing,
and
you
can
hook
into
how
this
feature
is
being
completed.
It
turns
out
in
most
systems
that
implement
features
today.
This
is
actually
how
it's
implemented.
B
You
have
some
sort
of
callback
based
system
where,
when
the
futures
are
done,
you
run
a
callback
and
then
that
might
go
and
further
in
schedule
some
more
callbacks,
so
I
want
to
dive
into
a
lot
of
details
here
about
we
have.
We
actually
went
down
this
road
quite
a
long
ways
before
we
ended
up
where
we
currently
are
today,
and
so
the
first
thing.
You'll
notice
is
this
bracket
F
and
is
fair
self,
and
so
this
crucially
means
that
this
tree
cannot
be
compatible
with
virtual
dispatch.
B
Is
not
what
we
call
object
safe,
that
came
to
turn
into
it
straight
objects.
Now,
doesn't
matter
so
much
about
the
details
of
why?
But
it
suffice
to
say
that
you
can't
erase
the
type
you
can't
have
virtual
dispatch.
You
can
only
kind
of
have
one
at
a
time
and
I'm
gonna
give
you
an
example
of
why
that's
actually
a
problem.
So
let's
say
you're,
just
writing
a
function
which
is
gonna,
take
a
key.
It's
gonna
have
some
sort
of
cache
to
immediately
immediate
return
values
and
otherwise
have
some
sort
of
slow
computation.
B
So
we'll
notice
here
that
we'll
look
up
my
cache
if
it's
ready
to
go
we'll
return,
a
feature
setting
up
this
is
done
and
then,
if
it's
not
done
we'll
go,
do
the
actual,
slow
computation,
that'll
fill
in
the
cache
and
all
that
good
stuff.
So
the
first
thing,
we'll
notice,
is
that
this
actually
doesn't
compile.
B
This
is
these
are
two
branches
of
an
if
statement
where
rust
will
require
that
these
are
the
exact
same
type,
and
these
are
two
different
types,
an
immediately
resolved
feature
and
then
a
delay
feature
that
will
take
a
little
bit
longer
to
actually
process
later
on.
So
if
we
try
and
solve
this
there's
actually
a
relatively
easy
local
solution,
we're
gonna
pack
this
in
an
either
you
know,
or
we
can
say
that
the
left-hand
side
is
returning
the
Avery,
the
a
variant.
B
The
right
hand,
side
is
returning
the
B
variant,
and
then
this
just
assumes
that
both
if
you
have
an
either
of
a
B
that
wants
future,
if
either
in
one
of
those
as
a
future-
and
then
just
kind
of
does
that-
and
this
works
great
enough
for
two
cases.
But
then
it
starts
being
a
problem
one,
so
you
get
even
more
cases.
So
what
if
we
have
more
conditions
where,
if
it's
less
than
four
you
do
one
thing:
it's
better
than
five
do
another
thing
and
we
might
get
this
problem.
What
happens?
B
We
have
27
cases
a
a
the
a
little
a
actually,
not
sure
what
the
conventions
are
there,
but
so
it
suffice
it
to
say
that
this
isn't
going
to
cut
it.
We
can't
have
just
an
enum.
We
can't
statically
say
that
this
is
the
number
of
branches
that
we're
going
to
be
taking.
What
we
really
need
here
is
type
erasure.
We
need
to
return
these
trade
objects,
so
this
box
of
future
these
creating
these
boxes
of
what's
actually
being
returned.
B
So
this
is
a
critical
feature
of
features
and
traits,
which
is
that
at
some
point
you
have
to
be
able
to
erase
the
type
and
you
have
to
able
to
say
that
I,
don't
know
what,
where
this
feature
came
from,
but
it's
still
a
feature
you
can
still
use
it
as
a
future.
So
having
this
ability
for
for
for
virtual
dispatch
ends
up
being
a
crucial
feature
that
we're
going
to
need
out
of
the
futures
trade.
So
we
come
back
here
to
our
definition
and
we'll
take
a
look
at
this
bracket.
B
Elfin,
this
self
and
we'll
say
all
right.
So
these
are
not
compatible
with
futures.
These
are
not
gonna
work
out.
I'm,
not
gonna,
go
in
the
details
as
to
why
they're.
So
it's
only
talk
in
and
of
itself,
but
this
is
an
alternate
signature
which
actually
is
object
safe
or
we
have
this
an
mute
self
and
this
box
at
FN
once
now.
B
So,
to
explain
that
here,
I
want
to
talk
about
kind
of
how
we
envision
servers
to
be
written
nowadays
with
Tokyo
and
kind
of
with
features
kind
of
what
the
style
for
that
would
be,
and
this
is
very
heavily
inspired
by
finagle
and
Scala.
If
you're
familiar
with
that,
where
the
fundamental
idea
is
that
your
entire
server
is
a
function
from
a
request
to
a
future
of
a
response
which
means
that
everything
you've
written
in
your
server
is
entirely
asynchronous.
B
It's
all
entirely
built
up
in
this
one
future,
and
it's
just
all
and
captured
in
that
one
thing,
and
then
the
the
framework
is:
what
takes
this
and
then
starts
processing
that
and
dealing
with
decoding
it
and
writing,
but
not,
and
so
you
might
have
a
server
which,
for
example,
it
receives
a
request
load.
Some
information
from
a
database
to
some
remote
API
calls
done
some
more
database
whatnot
and
finally
renders
a
response,
and
internally
we
can
notice
that
these
are
actually
all
creating
futures
in
the
middle.
B
B
So
if
we
kind
of
look
at
this
a
little
bit
graphically,
we
have
all
these
states
that
we're
gonna
go
through
the
first
state
is
we
have
a
request
and
then
we're
waiting
on
a
database
query
then
we're
waiting
on
an
API
query
so
on
and
so
forth
and
what's
actually
happening
here
is
we're
gonna
box.
All
this
up.
We're
gonna
put
this
all
into
one
giant
future,
and
this
is
what
we're
going
to
return
from
our
server.
B
So
our
server
is
then
responsible
for
returning
this
one
future
with
all
of
the
Steep
encapsulated
internally,
for
how
you're
actually
processing
this,
and
so
with
our
trait.
We
have
our
scheduled
function,
saying
when
this
future
is
done.
I,
like
you're
gonna,
run
this
callback
so
to
actually
progress
between
these
states.
We're
gonna.
Have
these
calls
to
schedule.
We're
gonna
say
when
this
loading
of
the
database
is
done.
B
That's
how
we're
progressing
between
these
states
we're
saying
that
every
time
we
make
a
state
transition
here,
we're
scheduling
a
call
back
saying
when
that
feature
is
done.
We'd
like
to
now
run
another
feature
and
when
we
start
scaling
this
up,
we
noticed
that
server.
The
because
of
the
server
is
in
the
server
response
is
entirely
a
future.
That
feature
is
tends
to
be
composed
of
many
other
features,
as
we
just
saw,
and
then
they
themselves,
as
we
saw
originally
fetching
an
API
request,
fetching
something
from
github
com.
B
That's
actually
gonna
take
a
lot
of
TLS
negotiation,
a
lot
of
internals
there,
so
that
entirely
is
made
up
with
many
many
other
features.
So
we
have
this
massive
tree
of
futures,
which
is
goes
far
beyond
what
we
actually
wrote
down,
because
everything
is
internally
made
of
futures
and,
as
a
result,
over
this
entire
request,
we
have
many
many
many
state
transitions
this
this.
B
This
concept
of
state
transition
is
almost
happening
every
time
bytes
come
in
off
the
network,
which
could
be
very,
very
frequent,
very,
very
rapid,
and
the
critical
thing
here
is
that
if
every
single
state
transition
actually
allocates
a
callback,
it's
incredibly
expensive
now,
for
this
kind
of
one
generally
only
allocated
five
callbacks.
That
would
be
fine,
but
what
we
wanted
to
do
is
we
want
to
push
the
boundaries
of
futures.
B
We
want
to
make
sure
that
you
can
use
futures
everywhere
up
and
down
the
stack
with
kind
of
a
uniform
interface,
and
that
requires
us
to
get
this
cost
down
even
further,
and
this
allocation
of
callbacks
is
just
not
gonna
cut
it
for
us,
but
it's
not
just
costs,
it's
not
just
runtime
cost.
It's
also
the
actual
API
cost
of
having
a
callback.
So
we'll
notice
here
that
we
have
this
box
of
FN
once,
but
we
didn't
say
anything
about
thread
safe
to
you
so
rust.
B
Has
this
trait
called
send
which
says
that
this
value
can
be
sent
across
other
threads?
It
has
sync
saying
that
you
can
actually
invoke
this
closure
across
many
threads
concurrently,
and
we
didn't
say
anything
about
that.
So
this
strict
definition
says
that
you
can
actually
only
run
completion
callbacks
on
the
thread
you
initially
had
it
on
now,
that's
not
actually
compatible.
If
you
have
two
threads
computing,
a
value
and
kind
of
want
to
fire
one
from
one
of
the
other.
B
But
then
the
problem
is
that
if
we
put
in
a
send
out
here
and
we've
required-
and
we
enabled
that
use
case
were
then
having
we're-
then
costing
the
other
use
case
of
I-
don't
need
the
thread
safe
futures
and
I
need
the
extra
speed
from
not
having
this
level
of
synchronization.
So
the
problem
here
is
we're
faced
with
an
uncomfortable
and
impossible
question
of
what
do
we
actually
do,
what
we
actually
assign
this
callback?
So
the
drawbacks
are
not
just
that.
This
is
incredibly
expensive
because
it
ends
up
being
very
expensive.
B
B
It
needs
to
be
necessary,
and
then
we
actually
experimented
with
a
couple
of
variants
of
thread
safe
and
non
thread,
safe
future
traits
where
you
have
kind
of
this
parallel
hierarchy,
but
it
ends
up
being
very,
very
difficult
to
use
and
essentially
impossible
to
make
sense
of
so
it's
suffice
to
say
that
callbacks
are
not
going
to
cut
it.
For
us.
This
ends
up
we've
at
this
point,
we're
not
gonna
be
able
to
use
callbacks.
This
traditional
way
of
blending
features
is
not
going
to
work.
B
So,
let's
recap
some
of
the
constraints
that
we've
seen
so
far
number
one.
We
need
to
be
a
tree.
We
have
to
allow
these
very
specialized
implementations.
We
can't
assume
that
anyone
is
going
to
be
sufficient
for
everyone.
This
trait
itself,
though,
has
to
also
enable
virtual
dispatch.
We
can't
compromise
on
that.
There
might
be
cases
where
we
don't
know
what
kind
of
feature
we're
going
to
be
returning,
and
so
we
have
to
be
able
to
erase
that
type
and
have
some
level
of
virtual
dispatch.
Theorem
state
transitions
are
happening
all
over
the
place.
B
We
can't
allocate
all
the
time
we
can't
make
sure
these
are
very
expensive.
These
this
we
need
to
optimize
for
as
many
state
transitions
to
happen
and
have
them
be
a
very
cheap
operation
and
then,
finally,
we
have
to
enable
these
thread
safe
cases
you
have
to.
We
can't
force
you
to
either
be
thread
safe
or
not
thread
safe
and
everyone
be
in
one
world
or
the
other.
B
We
have
this
fundamental
divide
where
there
are
legitimate
reasons
to
be
in
one
world
or
the
other,
and
simultaneously
use
those
in
the
same
application,
and
we
need
one
interface
to
kind
of
work
across
everything
so
to
solve
this
I'm
gonna
take
a
bit
of
a
larger
look
at
what
this
server
design
is
looking
like.
So
we
had
this
diagram
before
of
all
these
state
transitions
of
our
one
request.
B
We
have
our
big
feature,
which
internally
is
made
up
of
little
features,
and
so,
let's
zoom
out
a
bit
where
we're
not
just
processing
this
one
feature.
What
is
the
framework
actually
doing?
That
is
then
getting
this
feature
of
a
response,
and
what
it's
doing
is
it's
adding
all
of
its
own
layers,
saying
that
at
the
very
beginning,
it's
literally
reading
bytes
from
a
TCP
socket,
it
might
be
decrypting
them
doing
TLS.
It
could
then
be
decoding
some
to
be
protocol
one
or
two
or
whatnot,
and
then
once
it
finally
has
the
result.
B
It's
kind
of
no
one
task
has
futures
that
necessarily
related
to
other
tasks,
and
this
is
kind
of
just
a
canonical
architecture
that
we've
seen
in
many
asynchronous
servers,
and
so,
if
we
took
a
look
at
this,
we
can
actually
do
is
try
and
kind
of
model
a
set
of
futures
in
that
kind
of
a
runtime
system
around
this.
So
specifically,
we
have
the
a
task
is
composed
of
many
many
features
which
are
they
themselves
composed
of
many
many
other
features
internally,
but
everything
about
those
features
they
have
no
need
to
cross.
B
This
task,
they're,
typically
always
balanced
as
one
client
as
one
TCP
socket.
So
every
single
one
of
these
features
can
be
concrete,
Lee
named
or
connected
to
this
one
task
for
its
entire
lifetime.
Now,
while
that
task
is
alive,
it
might
have
many
features
which
are
active,
so
sometimes
it's
waiting
on
the
database.
B
So,
given
all
that
the
constant
this
kind
of
we
might
have
this
idea
of
tasks
in
here,
we
have
this
kind
of
concrete
idea
of
tasks
following
features
around
and
features
they're,
always
following
a
task.
Let's
try
and
redefine
in
our
treat
so
right
now
we
still
only
have
a
tree,
we
ever
type
item
and
the
next
thing
we
can
think
of
is
so
earlier.
We
were
saying:
when
are
you
done?
Please
do
this
when
this
is
done,
and
now
we
can
say
well,
let's
look,
they
are
we
there.
B
B
Are
you
ready
yet
it's
gonna
return,
none
saying
nope
I'm
not
ready,
yet
you're
gonna
have
to
come
back
at
a
later
time
or
it'll
return.
Some
so
yep
I'm
done
here's
the
value
and
then
the
only
problem
here
is
saying:
well,
okay,
if
you're
not
ready
at
how
do
I
actually
come
back
to
this
and
you'll
notice.
B
So
the
entire
lifetime
of
a
future
is
going
to
be
owned
by
a
particular
task
and
it
knows
what
to
notify
them,
and
so
the
task
is
the
one
that
has
to
come
back
and
actually
know
to
pull
this
feature.
So
when
we
see
none,
what
we
need
to
do
is
make
sure
that
the
task
is
notified
to
come
repol
this
feature
and
look
at
the
future
again
and
concretely.
B
That
means
that
there's
an
implicit
protocol
happening
here,
saying
that,
if
you
see
none,
then
implicitly
and
automatically
your
ambient
task
is
scheduled
to
receive
a
notification
that
you
were
then
ready
and
able
to
make
more
forward
progress.
So
it's
kind
of
a
lot
of
work,
so
I
want
to
kind
of
dive
into
a
bit
of
a
detail,
let's
kind
of
implement
a
simple
time-out.
B
This
is
just
a
a
feature
that
will
resolve
at
some
point
in
the
future
or
at
some
point
later
in
time,
and
so
the
first
thing
will
fill
out
some
struck
fields.
We
have
our
moments
which
we're
actually
going
to
fire
at,
so
this
is
just
kind
of
when
our
future
will
become
resolved,
and
then
we
have
some
auxilary
library
data
structures.
So
we
have
a
timer
here
which
has
this
one
function,
which
allows
us
to
run
a
closure
at
some
particular
point
in
time.
Now
the
DMM
tation
details
are
not
too
too
important.
B
This
is
mostly
just
how
we're
going
to
implement
our
future.
So
we'll
start
off
by
saying
it
will
feature
for
timeout
our
associative
type.
Is
this
going
to
be
a
unit
because
we're
not
actually
gonna
have
any
values
here?
When
the
futures
done
it's
going
to
say,
I'm
done,
that's
pretty
much
it,
and
then
we
have
our
poll
function.
So
the
first
thing
we're
gonna
do
our
and
our
poll
function
to
say
all
right.
Well,
if
the
timeout
has
elapsed,
then
we
are
done.
We
are,
can
now
return
sum.
B
We
can
never
turn
this
back
out
because
the
time
has
passed
for
this
actual
future
to
be
resolved.
You
have
correctly
pulled
me
at
the
right
time,
but
the
more
interesting
part
is
in
this
none
case,
and
the
real
thing
to
note
here
is
these
calls
to
task
current,
and
it's
calls
to
task
notify
so
what's
happening
here
is
the
when
we're
not
ready,
we're
gonna
return.
None
and
our
implicit
protocol
means
that
we
need
to
notify
our
task
when
we
otherwise
would
be
done.
B
So
the
definition
for
when
this
future
is
going
to
be
ready,
is,
at
this
point
in
time,
we're
now
ready
and
so
we're
using
this
auxilary
function
on
our
timer
kind
of
inside
of
our
struct
to
schedule
a
callback
to
be
invoked
at
some
point,
or
this
callback
is
going
to
actually
just
notify
the
task.
So
here
this
task
current
is
built
into
the
futures
crate.
B
This
is
kind
of
a
paradigm
brought
forth
in
features
how
you
actually
build
features
you'll,
pull
that
out
and
then,
when
you're
ready,
go,
call,
dot,
notify
and
then
I'll
then
queue
up
that
task
to
come
around
and
pull
this
feature
again
and
realize
it
actually
has
been
resolved
and
it's
able
to
make
for
and
it's
able
to
make
further
progress
all
right.
Let's
take
a
look
at
this
design
and
kind
of
how
it
matches
up
with
the
constraints
that
we've
had
so
far.
B
So
first
up,
we
have
our
constraints
of
a
trait
and
virtual
dispatch
and,
as
I
was
saying,
this
pull
based
solution.
It
does
obviously
is
a
tree
and
then
it
suffice
to
say
that
it
does
work
with
virtual
dispatch
and
we
argue
normal
outright
objects
from
this.
So
the
next
aspect
is
we
wanted
to
make
sure
that
these
state
transitions
were
cheap.
B
These
all
these
state
transitions
were
no
no
allocations
internally,
it's
all
just
happening
very
lightweight
manner,
and
so,
if
we
take
a
look
at
how
the
tasks
are
actually
implemented,
then
it
turns
out
that
when
you
spawn
a
future,
when
you
create
a
task,
when
you
can
create
this
giant
tree,
that's
one
allocation.
You're,
probably
gonna
have
to
have
some
sort
of
arc
some
sort
of
piece
of
chunk
of
memory
to
allocate
for
that
one
particular
task,
but
then
acquiring
a
reference
to
the
current
task.
B
You
don't
have
to
create
a
new
one,
you're,
just
referencing
the
ambient
tasks
that
you're,
always
part
of
and
so
acquiring
the
current
task
tends
to
just
be
in
a
breakfast
counts,
got
a
bump
a
reference
count.
Tamaki
I
tell
my
increment
all
that
good
stuff
and
the
notification
as
well
there's
no
extra
allocations
than
needed
there.
All
we're
gonna
do
is
put
ourselves
into
some
form
of
a
readiness
cue,
so
our
tasks
is
this
going
to
be
put
back
into
some
queue.
B
That
already
has
a
note
allocated
for
it,
and
we
can
say
this
is
ready
to
go
so
eventually,
it'll
get
processed
and
and
kumkum
come
back
to
that.
So
this
straight
about
cheap,
we
can
say,
we've
solved
that
as
well.
This
aspect
of
tasks
I
can
dive
more
into
the
into
the
details
later
today,
but
it
suffice
to
say
that
there
are
no
allocations
here.
While
these
features
are
executing
these
two
fundamental
functions
current
and
notify
are
basically
this
reference
counts
and
queuing
operations.
B
You
can
use
this
across
many
threads
concurrently,
and
this
ends
up
being
a
critical
feature
saying
that
this
tasks,
not
the
feature
itself
as
it's
disconnected
from
the
future,
is
able
to
be
sent
across
many
threads,
and
this
means
that
the
future
trait,
which
didn't
mention
callbacks,
didn't
mention
closures,
didn't
mention,
send
or
sync
allows
you
to
either
write
a
thread
safe
feature
or
a
non
thread
safe
future
in
kind
of
whatever
way
you
see
fit.
So
it
ends
up
a
lie.
B
B
So
that's
a
little
bit
about
the
task
of
futures
and
kind
of
how
we
end
up
empowering
these
very,
very
cheap
state
transitions
and
end
up
actually
solving
the
constraints
of
working
in
many
different
environments,
especially
related
to
threads
I,
want
to
talk
now
about
Tokyo
and
its
relation
to
tasks
and
how
we
actually
work
with
the
futures
there,
and
so
in
Tokyo.
It
is
critical
to
understand
that,
literally
everything
is
a
future.
B
The
entire
way
up
and
down
that
stack
I
was
showing
you
this
diagram
of
a
task
where
every
single
unit,
like
even
decrypting
SSL,
reading
bytes,
writing
bytes.
All
of
that
was
built
around
this
task
model
and
all
this
futures
model
so
you're,
seeing
a
uniform
model
of
futures
all
the
way
up
and
down
for
these
entire
IO
stacks
for
from
from
the
top
to
the
bottom.
B
But
it
means
that
every
single
along
the
way,
all
of
these
constructed
features
internally,
will
eventually
wait
for
some
IO
them
ie
to
wait
for
some
bytes
to
become
readable,
wait
for
some
bytes
to
become
writable,
and
so
Tokyo's
job
is
to
take
these
events
that
were
receiving
from
the
kernel
and
then
route
them
to
the
actual
tasks.
They're
waiting
on
them
so
have
a
task
that
is
gonna,
be
waiting
to
read
some
bytes
and
we
need
to
know
when
to
actually
wake
up
and
notify
that
task
to
move
forward.
B
So
before
this
was
the
a
service
IO
interface,
we
got,
we
were
trying
to
read
some
bytes
and
we're
gonna
immediately
see
that
here's
some
bytes
ready
to
go-
or
this
is
gonna-
be
woodblock.
Well,
what
we're
gonna
do
here
is
we're
gonna
kind
of
likely
do
the
futures
layer
on
an
implicit
protocol
here
where
what's
happening,
is
that
all
I/o
in
Tokyo,
like
I,
sync
I,
will
return
immediately.
B
None
of
it
will
ever
block,
but
this
written
this
notification
of
woodblock
is
an
implicitly
saying
that
your
task
is
now
ready
to
receive
a
notification
when
you
are
readable.
So
like
why
the
future,
if
you're
not
ready,
yet
you
will,
you
will
not
have
the
value
and
you're
scheduled
to
receive
a
notification
with
I/o
if
it's
not
ready.
Yet
you
know
you're
going
to
receive
a
notification
when
you
do
become
readable
when
you
do
become
writable
or
you're
gonna
finish
immediately
and
it's
going
to
actually
be
submitted
to
the
kernel.
B
So
this
allows
us
to
build
up
these
two
extension
traits
called
async,
read
and
async
right
and
you'll
notice
that
these
inherit
from
the
standard
read
and
write
traits,
but
what
they're
doing
is
they're
layering
on
these
contracts,
so
anything
that
implements
the
async
read.
Trade
is
not
walking,
so
it
will
never
block.
The
current
thread
will
always
return
immediately,
and
it
also
has
this
implicit
contract
saying
that
never
return,
woodblock
I'm
going
to
schedule
the
current
future
to
receive
a
notification
and
then
write
is
very
similar.
We're
right.
B
It
will
receive
a
notification
to
it
returns,
woodblock
and
then
we
also
add
this
shutdown
function
for
graceful
shutdowns,
where
typically,
this
is
handled
we
had
drop.
But
in
this
case
we
might
need
to
block
for
some
period
of
time,
so
this
is
kind
of
necessary
for
that
end
of
things,
and
so
these
are
mostly
just
marker
traits
saying
that
this
is
an
actual
compatible
IO
object,
but
I'm
going
to
show
you
how
one
of
these
might
actually
be
implemented.
B
So
you'll
find
this
in
the
Tokyo
library
of
this
Pola
vented
type
for
this
is
transforming
any
asynchronous
I/o
object
into
a
Tokyo,
asynchronous
I/o
object,
and
the
first
thing
we'll
notice
here
is
this
pole
read,
and
so
this
is
kind
of
a
convention
in
Tokyo,
where
any
function
prefixed
by
pole
is
interacting
with
the
task
system.
So
if
this
object,
we
know
for
a
fact,
it's
not
readable
we're
a
media
League
owing
to
return
woodblock
without
doing
any
I/o
and
we're
gonna.
This
implicitly
internally
will
schedule
our
tasks
notified.
B
So
we
know
that
because
we
are
returning
woodblock,
we
know
that
our
task
is
already
scheduled
to
be
notified,
so
we
don't
actually
need
to
do
anything
else.
We
can
this
kind
of
continue
to
return,
woodblock
and
move
out
from
there,
but
if
our
object
actually
says
that
it
is
ready,
we're
going
to
perform
the
read
operation
and
then
take
a
look
at
the
result
that
happens
afterwards.
So
if
the
result
from
the
actual
eye
operation
that
we
submitted
to
the
colonel
says
woodblock,
then
now
it's
our
responsibility.
B
We
have
done
no
interaction
with
the
task
system.
Yet
so
we
have
to
make
sure
we
block
our
task,
and
so
this
function
called
need.
Read
is
a
function
on
the
pole,
event
to
type
itself
and
it's
going
to
say
schedule
and
notification
when
this
object
is
readable
for
the
current
task,
and
so
you
might
be
able
to
start
seeing
this
where
this
pole
evented
object,
knows
the
TCP
socket
that
has
internally
and
then
so
we
now
we
know
the
task
that
we're
connecting
with,
and
we
know
we
need
it
to
be
readable.
B
So
you
can
kind
of
see
now
how,
when
the
colonel
says
that
follows
four,
four
five
is
ready
for.
Reading
tokyo
has
all
everything
it
needs
to
connect
that
up
and
say
well
now
that
test
means
to
go
wake
up,
so
we're
actually
translating
these
is
kind
of
very
obscure
events.
Coming
from
the
kernel
to
precisely
this
future
that
task,
they
can
now
explicitly
make
progress
and
start
and
start
working
on
this
object.
So
the
event
loop
is
the
one
that's
actually
responsible
for
blocking
the
current
thread.
It's
the
one!
B
That's
dispatching
all
these
events
that
we
received
from
the
kernel,
it's
kind
of
one
sitting
there
and
looping,
and
you
can
kind
of
see
how,
with
all
this
information,
we
now
know
precisely
were
to
actually
dispatch
these
events.
We
know
precisely
what
features
to
wake
up
and
you
no
longer
have
to
worry
about
correctly
routing
notifications,
correctly,
making
sure
the
system
is
actually
making
progress
and
so
effectively.
B
So
I
think
I
have
a
couple
minutes
for
questions,
and
so
this
these
are
the
links
for
Tokyo
itself,
the
project
on
github
and
the
features
create
itself,
and
you
can
also
also
go
those
and
I
think
I'll
be
in
the
the
networking
room
today.
If
you
have
any
toady
took
your
questions
with
Andrew
back
there
so
feel
free
to
drop
by
and
otherwise.
Thank
you
thank
you
here.
C
So,
with
a
sink
read
and
a
sink
right,
specifically
those
inherit
from
the
standard
read
and
write
trades.
If
you
have
a
case
where
you
have
a
read
implementation,
that
assumes
that
you're
in
the
context
of
an
executing
task.
So
if
you
actually
call
read
on
that
outside
of
a
task
you're
going
to
panic,
how
do
you?
How
do
you
deal
with
that
right?.
B
So
this
is
where
it
is.
The
having
a
current
task
is
something
that
is
currently
thread-local
in
the
futures
crate
and
if
you
do
not
have
a
current
task
and
you
otherwise
try
to
try
to
acquire
it.
So
if
we
just
if
I,
can
go
back
and
find
that
yes,
so
if
you
call
task
current
and
you're
not
actually
inside
of
the
context
of
a
test,
and
that
will
panic-
and
so
that
means
that
these
are
these
operations
like
this,
this
bear
read
tree.
B
This
bear
imitation,
will
indeed
panic,
and
so
currently
it's
mostly
set
up
where
that
ends
up
happening
very
rarely
most
of
the
time,
these
are
very
especially
IO
is
embedded
very,
very
deep
inside
of
futures,
but
otherwise
a
panic
is.
It
runs
like
an
actual
programmer
error.
It
ends
up
showing
up
very
very
quickly.
B
B
An
excellent
question
and
the
answer
is:
there's
no
roadmap.
The
dealing
with
asynchronous
file
systems
ends
up
being
very
difficult,
where
it's
like
kind
of
a
sinker
to
some
Windows,
but
apparently
not
really
I.
Don't
know
a
lot
about
the
details
there,
but
I
think
that's
definitely
on
UNIX,
there's,
basically
no
portable
interface
for
asynchronous
I/o.
B
So
right
now
for
file
system
operations,
you
tend
to
just
have
to
fork
out
to
a
thread
pool
you
have
some
thread
pool
actually
performing
blocking
operations,
and
then
you
have
some
sort
of
future
of
doing
that
result,
and
so
in
with
futures.
It
ends
up
being
very
ergonomic
and
very
easy
to
spawn
futures
on
thread
pools
and
then
continue
to
work
with
them
and
you're
just
using
question
mark
syntax,
the
whole
time
with
a
with
I/o
errors
and
those
kinds
of
objects.
B
So
it
ends
up
just
being
that,
because
it's
ergonomic
enough
to
kind
of
spin
that
up
and
spawn
off
that
work
and
just
get
the
results
back
out
in
an
asynchronous
fashion
that
it's
the
thread
pool
is
the
way
to
go
right
now
and
I.
Don't
think
there's
as
much
if
the
kernel
gives
us
the
ability
to
do
better,
we
do
better,
but
for
now
we
don't
have.
We
don't
have
much
of
an
option.
A
B
Yes,
actually
so
the
Tokyo
crate
doesn't
really
work
with
embedded
because
it
kind
of
assumes
Linux,
OSX
windows,
kind
of
stuff,
but
futures,
on
the
other
hand,
actually
is
compatible
with
embedded
systems
in
the
sense
that
there
is
a
no
stood
version
of
the
futures
crate
and
it
actually
still
gives
you
at
least
so
yeah.
It
gives
you
the
task
model.
It
gives
you
the
task
kind
of
a
test.
Current
tasks
notify
everything
there
is
built.
Like
you
strip
out
some
features
features
there
are
like.
You
can't
have
a
buffered
stream.
B
Is
you
can
construct
a
system
where
everything
instead
allocated
in
there
literally
are
no
runtime
allocations
and
ends
up
just
working
with
features?
We
haven't
actually
seen
features
used
in
the
embedded
context
yet,
but
it's
essentially
we
want.
We
always
wanted
to
have
it
empowered
to
work
at
that
layer,
cool.
E
E
So
my
question
is
this:
as
I
seen
your
timer
example,
you
use
current
task
context
to
reschedule
it.
Then,
if
task
is
the
assumed
the
single
entry
control
point,
why
not
pass
it
to
Paul
function
explicitly?
Otherwise
it
seems
like
non-trivial
implicit
dependency
like
if
you
want
to
reschedule
you'll
need
to
know
that
there
is
such
thing
as
tasks
in
some
module
and
stuff
there.
It's.
B
B
That's
a
very
good
question
and
we
definitely
add
that
a
lot,
so
the
decision
here
was
that
so
on
one
hand,
every
single
poll
function,
every
single,
every
single
function
and
features
is
sort
of
parametric
over
a
task.
So
we
could
have
the
entire
system
pass
pass
tasks
everywhere,
but
on
one
hand
that
is
a
little
a
little
unorganized.
B
So
this
is
an
example
actually
which
is
not
actually
possible
to
implement
in
that
kind
of
fashion,
where
this
is
going
to
work,
are
some
sort
of
thread-local
state
passing
going
on
there,
and
so
this
is
kind
of
one
major
motivating
example,
but
kind
of
the
other
aspect,
which
is
it's
already
everywhere.
It's
already
on
every
single
function
call,
and
so
it
ends
up
just
being
a
design
decision
where
it's
it's
more
ergonomic,
it's
already
happening
regardless.
It
doesn't
have
any
runtime
impact.
E
B
Could
do
that
it's
kind
of
its
kind
of
six
to
one
half
dozen,
really,
oh,
the
other.
At
that
point,
where
you,
you
could
have
two
systems
for
doing
it,
but
then
you
gotta
learn
two
systems.
It
is
a
little
cleaner
and
it's
I
think
a
lot
of
it.
A
lot
of
this
does
boil
down
to
and
that
there's
we
we
have
not
found
a
technical
reason.
B
F
Hi
so
I
mostly
played
with
the
Tokyo
level
and
I,
was
wondering
if
there
is
a
way
at
the
lower
levels,
it's
not
exposed
by
Tokyo
IO
to
prevent
getting
foals
when
there's
not
enough
bytes
in
buffer.
Maybe
so,
for
example,
I'm
reading
messages
and
I
know
I
need
at
most
at
least
30
bytes
can
I
prevent
those
contacts
which
is
for
the
first
29
bytes,
or
is
it
not
sensible
to
prevent
that
and.
B
By
context,
which
is
you
mean,
like
you,
you
pull
out
the
current
task
and
then
you
schedule
yourself
to
get
waited
because
you
only
got
one
byte
at
a
time
and
you're
kind
of
coming
back.
No
right
now,
there's
there's
no
way
to
do
that.
It's
it's
one
of
those
where
most
of
the
time,
if
you
end
up
having
a
blocking
operation
where
you're
not
able
to
resolve
it
at
that
point
in
time,
you're
already
very
much
on
the
slow
path.
B
So
the
fast
path
is
where
you
don't
even
touch
the
task
system,
you're
just
ready
and
you
just
keep
going
and
the
slow
path
is
where
alright
I'm
already
gonna
wait
for
multiple
milliseconds
to
wait
for
those
bytes
to
actually
come
in,
and
so
by
that
point
it
there.
There
is
no
way
to
actually
I
mean
you
could
busy
wait.
You
could
sit
there
in
the
future
and
spin
for
five
milliseconds
waiting
for
the
value
to
come
available.
B
You're,
not
quite
a
sync
at
that
point,
but
it's
kind
of
might
be
a
sick
enough
for
that,
for
that
particular
use
case.
But
in
general,
there's
no
way
to
avoid
that
you'll
have
to.
You
are
forced
to
then
get
the
task
put
it
somewhere
and
then
go
through
the
whole
machinery
of
load,
balancing
and
whatnot.
But.