# 1.46.1 (July 4th, 2025)
This release fixes incorrect spawn locations in runtime task hooks for tasks
spawned using `tokio::spawn` rather than `Runtime::spawn`. This issue only
effected the spawn location in `TaskMeta::spawned_at`, and did not effect task
locations in Tracing events.
## Unstable
- runtime: add `TaskMeta::spawn_location` tracking where a task was spawned
([#7440)])
[#7440]: https://github.com/tokio-rs/tokio/pull/7440
## Motivation
Unfortunately, due to an oversight on my part, the capturing of spawn
locations was only tested with the `Runtime::spawn` method, and *not*
with `tokio::spawn`/`tokio::task::spawn`, which is how most tasks are
spawned in Real Life. And, it turned out that because this was not
tested...well, it was broken. Agh. My bad.
## Solution
Although the whole call chain for spawning tasks using `tokio::spawn`
was correctly annotated with `#[track_caller]`, the location wasn't
propagated correctly because of the `context::with_current(|handle| {
... })` closure that accesses the current runtime. Because the call to
spawn the task occurs inside a closure, the *closure*'s location is
captured instead of the caller. This means any task spawned by
`tokio::spawn` records its location as being in
`tokio/src/task/spawn.rs`, which is not what we'd like. This commit
fixes that by capturing the spawn location outside the `with_current`
closure and passing it in explicitly.
I've updated the tests to also spawn a task with `tokio::spawn`, so that
we ensure this works correctly.
As described in issue #7411, task spawning APIs are currently annotated
with `#[track_caller]`, allowing us to capture the location in the user
source code where the task was spawned. This is used for `tracing`
events used by `tokio-console` and friends. However, this information is
*not* exposed to the runtime `on_task_spawn`, `on_before_task_poll`,
`on_after_task_poll`, and `on_task_terminate` hooks, which is a shame,
as it would be useful there as well.
This branch adds the task's spawn location to the `TaskMeta` struct
provided to the runtime's task hooks. This is implemented by storing a
`&'static Location<'static>` in the task's `Core` alongside the
`task::Id`. In [this comment][1], @ADD-SP suggested storing the
`Location` in the task's `Trailer`.
I opted to store it in the `Core` instead, as the `Trailer` is intended
to store "cold" data that is only accessed when the task _completes_,
and not on every poll. Since the task meta is passed to the
`on_before_task_poll` and `on_after_task_poll` hooks, we would be
accessing the `Trailer` on polls if we stored the `Location` there.
Therefore, I put it in the `Core`, instead, which contains data that we
access every time the task is polled.
Closes#7411
[1]: https://github.com/tokio-rs/tokio/issues/7411#issuecomment-2993377045
* tests: handle spurious EWOULDBLOCK in io_async_fd
## Motivation
The `io_async_fd.rs` tests contain a `drain()` function, which
currently performs synchronous reads from a UDS socket until it returns
`io::ErrorKind::WouldBlock` (i.e., errno `EWOULDBLOCK`/`EAGAIN`). The
*intent* behind this function is to ensure that all data has been
drained from the UDS socket's buffer...which is what it appears to
do...on Linux. On other systems, it appears that an `EWOULDBLOCK` or
`EAGAIN` may be returned before enough data has been read from the UDS
socket to result in the other end being notified that the socket is now
writable. In particular, this appears to be the case on illumos, where
the tests using this function hang forever (see [this comment][1] on PR
#6769).
To my knowledge, this behavior is still POSIX-compliant --- the
reader will still be notified that the socket is readable, and if it
were actually doing non-blocking IO, it would continue reading upon
receipt of that notification. So, relying on `EWOULDBLOCK` to indicate
that the socket has been sufficiently drained appears to rely on
Linux/FreeBSD behavior that isn't necessarily portable to other Unices.
## Solution
This commit changes the `drain()` function to take an argument for the
number of bytes *written* to the socket previously, and continue looping
until it has read that many bytes, regardless of whether `EWOULDBLOCK`
is returned. This should ensure that the socket is drained on all
POSIX-compliant systems, and indeed, the `io_async_fd::reset_writable`
and `io_async_fd::poll_fns` tests no longer hang forever on illumos.
I think making this change is an appropriate solution to the
test failure here, as the `drain()` function is part of the test, rather
than the code in Tokio *being* tested, and (as I mentioned above) the
use of blocking reads on a non-blocking socket without a mechanism to
continue reading when the socket becomes readable again is not really
something a real life program seems likely to do. Ensuring that all the
written bytes have been read by passing in a byte count seems more
faithful to what the test is actually *trying* to do here, anyway.
Thanks to @jclulow for debugging what was going on here!
This change was cherry-picked from commit
f18d6ed7d4 from PR #6769, so that the fix
can be merged separately.
[1]: https://github.com/tokio-rs/tokio/pull/6769#issuecomment-2284753794
Signed-off-by: Eliza Weisman <[email protected]>
## Motivation
As described in #6763, Tokio compiles for the [illumos] operating
system, but we don't presently have automated tests on illumos. We would
like to add illumos CI jobs for Tokio using [Buildomat], a CI system
which supports illumos. Buildomat CI jobs for Tokio will run on
infrastructure contributed by Oxide Computer Company.
In order for Buildomat to watch for commits to the repo, we must first
add a configuration file in `.github/buildomat/config.toml` with the
`enable = true` key. This config file must be present on the repo's main
branch for Buildomat to enable builds for the repo. See [here] for
details.
## Solution
This branch adds a `.github/buildomat` directory containing a config
file and a README summarizing what the configs in that directory are
for, as well as documenting how to get help diagnosing illumos CI
failures.
This branch does *not* add scripts for actually running CI jobs on
Buildomat. Since the config file must be present on the repo's main
branch before Buildomat runs CI jobs for the repo, I'd like to merge the
config file separately from the actual build scripts. This way, I can
actually have the build jobs run on the PR that adds them, making it
easier to ensure everything is working correctly before merging.
Closes#6766, which is obsoleted by this branch.
[illumos]: https://www.illumos.org/
[Buildomat]: https://github.com/oxidecomputer/
[here]:
https://github.com/oxidecomputer/buildomat/blob/main/README.md#per-repository-configuration
