Skip to content

perry-ext-pg and perry-ext-mysql2 use plain spawn_blocking instead of spawn_blocking_with_reactor for socket I/O #10339

Description

@proggeramlug

Problem

perry-ext-pg and perry-ext-mysql2 use plain spawn_blocking — not spawn_blocking_with_reactor — for real socket I/O. perry_ffi_async.rs:252-278 documents that plain spawn_blocking panics with "there is no reactor running" for exactly this kind of work, which is the stated reason spawn_blocking_with_reactor exists as a second shim (already used correctly by net/ws/http).

Why it matters

This evidently works today only because binding_needs_shared_tokio forces a shared tokio compilation for these bindings — but nothing in the code states that this indirect mechanism is what's actually making the unsafe-looking call safe. That makes it fragile: a change to binding_needs_shared_tokio's behavior, or to how these bindings are compiled, could silently reintroduce the "no reactor running" panic with no obvious connection to its cause.

What would fix it

Switch perry-ext-pg and perry-ext-mysql2 to spawn_blocking_with_reactor to match net/ws/http's already-correct pattern, removing the implicit dependency on binding_needs_shared_tokio's side effect — or, short of that, document explicitly at both call sites why the plain spawn_blocking call is safe here and what would break that invariant.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions