►
Description
In this session, Zeeshan (https://twitter.com/zeenix) will walk us through the challenges of implementing an async library that's agnostic to the various current and future async runtimes. We will also look into possible solutions and workarounds to these challenges by following Zeeshan's personal journey with zbus, a D-Bus crate that is runtime-agnostic.
Special Thanks to Microsoft for their support
Rust Linz: https://rust-linz.at - https://twitter.com/rustlinz - https://sessionize.com/rustlinz
A
A
But
let's
see
how
how
life
goes
and
I'm
a
freelance
software
engineer,
and
the
funny
thing
is
that
daniel
mentioned
g
streamer
and
that's
that's
the
first
project
I
got
into.
Actually
I
wasn't
even
out
of
my
uni
yet
and
I
got
into
it
and
it
was
like
2001
the
beginning
of
that
project.
Even
and
I
was
one
of
the
first
users
and
I
made
a
video
wall
out
of
it.
So
my
sis,
my
background,
is
more
like
systems
programming
and
I've
also
been
involved
very
much
in
ganon.
A
That
was
also
mentioned,
but
recently
I've
been
more
into
cloud
and
now
about
beckons
and
rust,
and
for
the
last
four
or
five
years
I've
been
super
into
interest.
Yeah
and
yeah.
As
I
said
mostly,
I
might
have
a
background
in
free
and
open
source
software,
and
these
are
my
passions
and
and
likes
I'm
into
flying.
A
I
have
flying
licenses
and
I
have
three
cats
so
about
the
talk
a
bit
of
background
first
before
I
dive
into
it
because
there's
this
is
some
complicated
subject
and
I'm
not
sure
most
audiences
have
even
used
async
much
in
in
rust
asynchroid.
So
what
is
it
about?
Do
you
think
a
weight
in
rust?
It's
it's
like
a
normal
flow
of
a
program
right
like
you
when
you
write
synchronous
or
as
I
would
call
it
blocking
code.
A
Actually,
it
only
returns.
You
a
future
something
called
a
future
and
that
future
needs
to
be
awaited.
It
doesn't
it's
the
future
like
what
does
it
even
mean
right
and
it's
these
functions
are
returning
something
called
a
future
right.
It's
a
type
in
standard
library
and
yeah
what
I've
always
dreamed
of
seeing
the
future.
What
is
the
future
anyway
and
the
future
is
a
very
simple
trait
it's.
It
has
an
output
just
like
a
normal
function.
A
Right
functions
usually
have
an
output,
and
this
has
one
method
only
and
that's
paul.
It's
it.
It's
a
bit
scary
when
you
look
at
it,
but
it's
actually
not
that
scary
in
the
end,
if
you,
if
you
know
what's
what's
it
about,
it's
only
has
two
parameters
right,
but
the
main
point
here
is
that
it
has
a
pull
and
you
have
to
call
it.
A
You
have
to
call
this
function,
and
so,
when
you
in
rust,
what
it
does
is
like
when
you
have
an
async
function,
it
translates
it
into
this,
so
the
async
is
removed
from
the
function
and
the
return
value
becomes
an
impul
future,
and
the
output
of
that
future
is
what
you
declared.
The
output
of
the
function
to
be
right
and
futures
these
features
are
inert
in
rust.
They
don't
run
on
it
on
their
own
until
you
explicitly
run
them
somehow.
A
A
There
are
some
some
that
are
very
specific
use
case,
they're
designed
for
specific,
very
specific
use
cases.
Some
are
more
generic
like
tokyo
and
async
ted
are
very
generic
ones,
and
what
what
do
these
runtimes
actually
do?
Right
like?
How
do
you?
How
do
you
consume
those
those
futures
or
or
run
actually
run
those
async
functions
that
you
declared
previously
to
completion?
A
This
is
a
async
example
is
instead
example,
but
tokyo
provides
a
very
similar
api
for
for
blocking
one
and
all
of
them
do
like
there's
a
block
on
methods.
I
think
in
almost
all
run
times
exactly
the
same
name,
and
there
are
main
wrappers
provided
as
well,
so
you
don't
want
to
to
block
on.
They
provide
attributes,
attribute
macros,
where
you
declare
where
you
are
able
to
declare
your
main
function
as
async,
then
the
rust
by
default.
A
Doesn't
you
know,
provide
it
out
of
the
box
this,
so
the
runtimes
provide
this,
and
also
because
you
need
a
runtime
to
make
it
happen
and
rust
cannot
assume
at
a
specific
run
time.
So
that's
why
it
can't
be
there
right
at
least
right
now
and
then
there's
spawning
spawning
is
actually
like
how
futures
and
async
works
in
other
programming
languages,
usually,
which
is
when
you,
when
you
call
something
an
async
function.
It
starts
running
on
its
own,
but
and
in
in
rust.
A
You
have
something
called
spawning
a
task,
a
concept
like
that,
where
you
say
I
want
to
start
it
now,
this
async
block
or
function,
and
it
will
just
spawn
it
immediately.
Yeah.
It
depends
a
bit
so
tasks
in
async
world
is
very
similar
to
threads
in
in
in
the
synchronous
world,
except
that
tasks
could
be
threads
in
multi
multi-threaded
runtimes,
but
it
doesn't
necessarily
have
to
be.
A
There
are
single
threaded
runtimes
as
well
and
in
the
same
runtimes
there
is
options
to
to
use
whichever
you
want
to
use
for
for
your
use
case.
So
yeah
it
could
be
threads,
it
could
be
not
threads,
but
they
are
similar
in
the
concept
because
you
spawn
them
and
then
you
can
wait
on
them.
You
can
yeah.
You
can
wait
for
for
them
to
finish,
just
like
you
do
with
threads
yeah.
A
So
that's
what
we
are
doing
here
like
just
pointing
to
tasks
and
and
then
just
sleeping
giving
them
a
time
time
to
finish
so
runtime
agnostic,
libraries
right,
that's
what
you
came
here
for
I
have
to
say
that
you
might
be
disappointed
with
my
talk
and
it's
not.
I
don't
have
a
lot
of
good
news.
Some
a
lot
there's
a
lot
of
bad
news
and
some
good
news
here
so
be
prepared
and-
and
the
reason
I
am
doing.
A
This
is
because
I
have
been
maintaining
and
developing
a
library
called
zebus,
which
is
an
ipc
library
and
the
main
point
of
that,
because
it's
an
ipc
library,
the
main
thing
is
io,
and
this
is
where
you
really
need
async,
you
really
want
async
and
our
first
version,
zebras,
one
or
1.2
was
fully
synchronous.
We
added
some
async
bits
later,
but
it
wasn't
really
async
and
with
2.0
it's
now,
primarily
async
actually
with
the
synchronous
parts
are
now
just
wrappers
around
the
async.
A
Actually
so
so
I
bumped
into
all
these
issues
that
are
there
because
of
having
different
kinds
of
runtimes
and
them
being
incompatible.
So
so
I
decided
that
maybe
I
should
share
the
knowledge
I
gained
from
that
time
and
and
it
would
be
useful
for
others,
I
hope
so
read
from
file
right.
We
either
the
code
I
shared
before
that
I
didn't
implement.
A
Actually,
let's
implement
that,
let's
assume
it's
part
of
our
new
library,
which
is
needs
to
be
asynchronous,
because
it's
reading
from
a
file,
so
it's
io
so
but
it
could
be
a
socket.
It
could
be
anything
and
let's
do
it
like.
So
how
do
we
do
it
like?
We
need
some
kind
of
async
api
to
read
files
and
one
of
the
apis
would
be.
I
guess,
tokyo
right
and
the
async
stud
provides
something
similar
most
likely
the
same.
A
I
haven't
checked
actually,
but
I
checked
it
a
while
ago,
but
I
don't
remember
but
yeah
it's
very
similar,
so
we
choose
tokyo
for
this
one
right
and
we
use
the
file
open.
Just
like
you
would
do
in
synchronous
code.
Just
the
difference
is
that
you
would
await
it
and
your
function
is
async
now,
and
this
does
the
job
and
client
code
works.
Just
fine
client
code
just
calls
it
and
waits
for
it
in
their
basic
main,
all
good.
A
A
A
There
is
a
subtle
difference
between
reactor
runtime
and
there
is
another
term,
but
for
the
sake
of
this
conversation,
they're
very
similar
and
they're
used
interchangeably.
Actually,
so
that's
not
it.
The
other
one
is
executor.
So
executor
is
something
very
similar,
but
it's
used
interchangeably.
So
we
will
do
the
same
for
simple
simplicity
here
so
yeah
it
resumes
a
runtime.
So
we
can't
do
that
and
the
other
problem
that
you
will
have
when
you
write
async
libraries
right.
You
will
need
to
spawn
a
task.
A
A
For
example,
in
zebras
we
had
to
have
like
a
we
have
a
connection
which
is
like
back
by
socket
and
we
can
have
multiple,
like
maybe
hundreds,
maybe
even
thousands,
of
streams
that
need
to
read
at
the
same
time,
from
the
same
socket.
How
do
we?
How
do
we
do
that?
How
do
we
accomplish
that?
We
tried
different
ways,
including
you
know,
locks
and
stuff,
but
that's
like
a
really
really
messy
and
it
can
easily
deadlock
like
we
had
so
many
deadlocks
developing
that
code.
A
Ultimately,
I
gave
up
and
went
for
other
approaches
and
in
the
end
we
ended
up
with
this
approach.
Where
we
have
a
broadcast
channel
and
the
the
sender
is
just
receiving
from
socket.
It
has
only
access
to
the
socket
itself
and
all
these
streams
are
just
receiving
on
that
broadcast
channel.
So,
each
time
something
comes
on
the
socket
that
you
know
receive
sorry,
the
sender,
the
broadcast
sender
sends
it
to
all
the
streams,
but
how
does
it
work?
Someone
has
to
be
there?
A
Someone
has
to
be
reading
the
socket
who,
who
is
the
sender?
What
is
the
sender
so
there
has
to
be
a
thread
right
or
some
task.
If
it's
a
task
which
one
time
would
it
be
like,
we
are
assuming
no
runtimes
remember,
or
at
least
we
want
to
not
assume
any
runtime.
So
how
do
we
accomplish
this?
So
that's
one
another
problem
and
another
very
related
problem-
is
async,
callbacks
or
any
kind
of
user
code.
A
That
user
gives
it
to
you
when
you
have
to
run
it
doesn't
have
to
be
necessarily
callbacks.
There's
other
examples
of
that.
So
if
it's
async,
how,
how
do
you
wait
for
it?
As
I
said,
you
need
a
runtime
for
for
waiting
on
on
async
you
to
to
execute
the
the
future
till
completion.
So
how
would
you
possibly
do
that
without
assuming
a
runtime
solutions
and
no
perfect
solution?
I
warned
you,
you
will
be
disappointed
and
yeah,
I'm
sorry
there
isn't
any.
A
So
if
you
just
want
to
be
compatible
with
most
apps
and
you
want
to
make
them
happy,
it's
the
easy
way
out-
you
just
do
it,
and
and
just
but
then
you
you
have
to
be
okay
with
the
cons
which
is
you're
requiring
tokyo
and
it's
not
like
tokyo
is
always
possible
to
use
for
for
the
apps.
There
is
many
use
cases
where
tokyo
at
least
right
now
would
not
fit
it's
a
very
generic
runtime.
It's
a
very
generic
api,
and
it's
very
good
at
that.
But
for
specific
use
cases.
A
Let's
say
you
want
to
do
something
for
embedded
systems
where
you
have
very
limited
resources,
you
don't
want
you,
you
would
ideally
want
something
that
doesn't
even
allocate-
or
at
least
it
doesn't
assume,
std
library.
So
you
can't
use
tokyo
there,
because
currently
it
doesn't
support
nostalgic
and
even
if
it
did,
it
doesn't
support.
No,
no!
I
look
at
least
so
yeah.
That's
would
be
one
example,
but
I'm
sure
there
are
other
examples
where
you
just
it's
just
not
feasible.
A
So
you
need
to
be
okay
with
that
that
your
on
for
those
use
cases,
your
api
would
not
be
useful.
Yeah.
As
I
said,
it's
not
always
possible
use
yeah.
The
second
approach
which
I
started
with
in
zebus
in
the
beginning
was
use
runtime
agnostic
crates
and
there
are
some
out
there
and,
for
example,
the
primary
one
that
we
used
and
also
I
somehow
ended
up
becoming
the
maintainer.
Well
one
of
the
many
maintainers
of
it.
A
It's
it's
a
it's
a
project
called
small
rs.
It's
also
a
runtime,
a
very
small
run
time,
but
it's
more
like
a
runtime
kit.
So
it's
just
divided
into
small,
very,
very
small
sub
crates
that
make
up
make
it
up
and
yeah.
They
provide
different
functionalities
like
for
io.
You
would
use
async
io
for
channels.
You
would
do
async
channel
broadcast
async,
broadcast
and
stuff
like
that.
A
I'll
go
through
with
some
of
these
in
a
bit,
and
some
of
them
are
truly
is
like
they're
agnostic
to
to
runtime.
They
don't
have
to
do
anything
weird
to
do
that.
Like
async
channel
async
broadcast
especially
there,
they
don't
assume
anything
the
others
don't,
but
as
well.
Actually,
but
there
are
some
some
cons
I'll
talk
about
it
in
a
bit,
so
the
pros
you,
you
will
be
using
a
runtime
agnostic.
Mostly
there
is.
A
There
is
a
one
small
thing
that
I'll
talk
about
later,
but
mostly
you
are
compatible,
so
so
you're
good
and
then
cons
yeah.
It
has
to
launch
threads
at
least
some
of
those,
and
one
of
them
is
async
io,
and
the
reason
is,
if
you
remember,
I
showed
you
the
the
future
trade,
the
poll
method.
It
also
gets
like
a
context.
So,
as
I
said,
runtime
calls
the
poll
continuously
until
the
the
future
is
resolved,
but
it
doesn't
easy
loop.
It
doesn't
keep
calling
it
in
in
a
loop
it.
A
It
calls
it
only
when
it's
ready
and
how
do?
How
does
it
know
when
it's
ready?
There
is
the
in
the
context
that's
passed.
There
is
also
a
waker,
so
the
the
runtime
gives
away
to
the
future
implementation
to
call
it
back
when
it's
ready,
and
so
how
would
that
be
accomplished
and
the
the
main
way
is
to
to
use
threats
and
async?
I
o
is
no
exception.
A
What
this
does
is
that
you
have
a
small,
really
tiny
runtime,
if
you
use
it
inside
of
your
library
like
zebus
does
and
how
we
use
it.
Is
we
all
the
chores
that
I
mentioned,
that
we
have
to
do
inside
the
library
and
all
the
user
callbacks
that
we
need
to
call?
They
are
done
as
a
task
on
this
executor,
and
this
executor,
of
course
needs
to
be.
A
A
So
that's
that's
a
bit
of
a
problem,
but
this
you
can
accomplish
with
threats.
This
is
how
we
did
it
in
zebras
and
you
can
of
course,
also
do
it.
So
by
default,
we
we
run
a
thread
that
that
runs.
This
sticks
this
this
executor,
but
you
don't
necessarily
need
threads.
Actually,
what
you
can
provide
is
like
we
do
in
in
zebras.
This
is
a
zippers
example
is
like
we
have
a
connection
builder.
A
That
connects,
creates
the
connection,
but
at
the
same
time
you
can
tell
it
to
disable
the
internal
thread
that
we
were
going
to
launch
for
you
and
then
once
you
have
the
connection.
What
you
can
do
is
run
that
with
your
own
runtime,
like
whether
in
this
case
it's
tokyo,
but
it
could
be
any
runtime
and
you
can
spawn
a
task
and
then
you
can,
just
you
know,
execute
like
sorry,
tick,
the
executor
and,
as
you
can
see,
that
itself
is
also
async.
A
So
but
it
as
I
said,
it's
still
100
compatible
with
tokyo,
and
the
main
thing
is
the
user
code
that
you
need
to
run
because
if
you're,
if
there
is
no
tokyo
runtime
running
and
then
you
call
something
that
is,
that
is
a
tokyo
api.
It
will
assume
a
tokyo
run
time
and
it
will
fail
because
there
is
no
talking
run
time
running.
But
if
you
do
it
like,
we
are
doing
here.
Of
course,
there
is
a
run.
A
Then
tokyo
run
time
running
everything,
so
it
will
be
okay,
but
that
assumes
that
there
is
a
and
you're
from
outside
you.
You
do
this
yourself,
which
is
a
bit
of
manual
work.
It's
not
a
lot
of
work
as
you
can
see,
but
still
it's
on
you
as
a
user
to
to
do
this,
and
users
can't
be
expected
to
remember
this
right.
So
yeah,
it's
not
out
of
the
box
working.
So
another
compromise
that
we
ended
up
in
zebras
in
the
end
was
to
do
both.
And
what
does
it
mean
by
that?
A
It's
you,
you
use
a
feature,
cargo
features
and
you
and
yeah
you.
By
default.
You
use
something
like
async
io,
but
people
should
be
able
to
disable
that
as
like,
when
you,
you
know,
you
can
disable
default
features,
and
then
you
can
enable
tokyo
feature
and
once
you
do
that
internally,
we
can,
you
know,
handle
it
like.
A
But
now
user
has
a
very
easy
way
of
accomplishing
like
if
they
are
using
tokyo
and
don't
want
to
bother
with
anything
they
can
now
do
that
and
yeah
they
don't
they
don't
have
to
care,
and
the
pros
of
this
is
yeah
user
doesn't
need
to
do
much
at
all,
just
declaring
it
right
in
the
cargo
tunnel
and
that's
it
and
the
cons.
It
really
complicates
the
library
code
right.
Let
me
show
you
an
example.
A
This
is
just
a
like
a
small
part,
like
of
of
the
code
that
we
had
to
do,
and
you
know
we
have
to
we
had
to
write
in
in
zebras.
You
you
need
to,
you
know,
have
a
lot
of
these
cfgs
in
the
code.
Well,
we
ended
up
with
not
as
many
as
I
thought
would
we
would,
but
still
it's
it's
a
lot
more
than
I
would
want,
and
I've
heard
there's
now
crates
that
actually
abstract
this
I
haven't
tried
those-
maybe
maybe
I
can.
A
But
that's
how
it
is
I'm
sorry,
but
there
is
some
hope
there
is
an
async
working
group
for
a
while
now
for
many
months
half
a
year.
I
think-
and
I
was
actually
in
the
end,
sorry
in
the
beginning,
part
of
that
and
provided
as
much
feedback
as
I
could
and
and
make
sure
that
the
people
actually
working
on
that
stuff
to
make
it
better
the
async
parts
of
rust.
A
They
know
all
the
problems
that
exist
and
and
and
they
are
they
have
proposals
they
have
yeah.
They
have.
They
have
ideas
of
how
to
improve
things.
I
I'm
not
sure
how
much
would
they
be
able
to
achieve,
but
because
it
needs
a
lot
of
collaboration
with
the
with
the
runtime
folks
right,
the
the
maintainers
and
stuff,
and
they
might
not
have
the
same
priorities
as
the
async
working
group
or
the
upstream.
A
There
is
there's
ideas
for
creating
some
traits
and
abstractions
in
general
for
for
different
runtimes
in
the
in
the
standard
library,
so
that
you
can.
You
can
have
some
generic
api
that
you
don't
need
to
assume
a
specific
runtime
to
to
do
specific
things.
So
yeah
we're
looking
forward
to
that
once
that's
that's
there.