Add v8::Locker, v8::Unlocker, and UnenteredIsolate bindings

[max-lt]

Adds bindings for multi-threaded isolate pooling, enabling architectures like Cloudflare Workers.

Changes

• UnenteredIsolate: New isolate type without auto-enter, removes LIFO drop constraint
• v8::Locker: Acquires exclusive thread access to an isolate
• v8::Unlocker: Temporarily releases a lock
• unsafe impl Send for UnenteredIsolate (safe with Locker)

Key Features

• Drop isolates in any order (no LIFO panic)
• Share isolates across threads with Arc<Mutex<UnenteredIsolate>>
• <10µs warm start vs ~3-5ms creating new isolates
• 10,000+ req/s throughput per cached isolate

Tests

• 298 lines of tests including multi-threaded usage, no LIFO constraint, concurrent access prevention
• Working POC with cooperative multitasking: https://gist.github.com/max-lt/2201664fbb7d6fef432da4f91b2eb004

Note: Each thread must call unsafe { isolate.enter() } before use to setup V8's thread-local state.

No breaking changes - all new APIs

[CLAassistant]

All committers have signed the CLA.

[devsnek]

To make this actually safe, v8::UnenteredIsolate can not deref into v8::Isolate. I would suggest that v8::Locker::new() accepts an &mut UnenteredIsolate and derefs into v8::Isolate instead. v8::Unlocker is also a huge can of worms wrt aliasing. I'd suggest leaving it out for now.

Also, v8::Locker internals don't belong in scope code, and you don't really need to make separate raw types for them. You should also avoid hard-coding sizes like [usize; 2]. In binding.hpp you can expose either v8::Locker, or the size of v8::Locker if exposing v8::Locker is too complex for bindgen.

Also, these ai generated comments and pr descriptions are really fucking annoying. You need to take responsibility for what you are submitting, rather than just assuming claude will be correct. unsafe impl Send for UnenteredIsolate (safe with Locker) is wrong! Regardless of what the comment says, the drop implementation of UnenteredIsolate is unsound!

[max-lt]

Will rework, thanks for the review

[max-lt]

Applied requested changes. Let me know if I missed anything.

[RainyPixel]

I would also like to help with MR. Do you need any help, or can I contribute to speed up the merge with the main code?

[max-lt]

Thanks @RainyPixel for offering help! I'd really appreciate it.

Honestly, what I need most right now is a thorough code review. I believe the current implementation addresses @devsnek's safety concerns, but having fresh eyes on it would really help move this forward.

In the meantime, we maintain a working fork at https://github.com/openworkers/rusty-v8 (currently at v145 with ptrcomp & sandbox feature flags) that we use in production for https://github.com/openworkers/openworkers-runner. It's also published on crates.io as https://crates.io/crates/openworkers-v8. The isolate pooling works well for our use case. Feel free to check it out if you want to see the implementation in action.

[max-lt]

@RainyPixel's follow-up commit adds panic safety for the Locker::new() initialization path and some compile-time safety tests.

Ready for review when you have time.

[max-lt]

Commit de789a7 makes Locker a pure mutex, add IsolateScope for Enter/Exit

Previous changes introduced Locker + unentered isolates to avoid OwnedIsolate's LIFO drop constraint. But the Locker itself still called Enter()/Exit() internally, which reintroduced the same LIFO constraint at the Locker level, when multiple Lockers for different isolates coexist on the same thread (async pool), dropping them out of order still corrupts the entry stack.

Last fix completes the decoupling:

• Locker → pure mutex. No more Enter/Exit.
• IsolateScope (new) → RAII Enter()/Exit(), short-lived around each synchronous V8 block, always properly nested.

  let locker = v8::Locker::new(&mut isolate);   // mutex only
  let _scope = locker.enter();                  // Enter(isolate)
  // ... V8 work ...
  // _scope dropped → Exit(isolate), before any await
  // locker dropped → unlock mutex, safe in any order

Tests: 10 safety tests (non-LIFO drop, concurrent lockers, stress) + 6 IsolateScope tests (interleaved isolates, round-robin).

[max-lt]

de789a7 called Enter()/Exit() during Locker construction, attempting to influence top_level_ in the C++ Locker. This was unnecessary, Locker::Initialize() determines top_level_ via RestoreThread() (archived thread state from Unlocker pairs), not via the entry stack. Since we never use Unlocker, top_level_ is always true, which correctly calls FreeThreadResources() on drop.

5b42bdd Removed the dead Enter/Exit calls and the IsolateExitGuard. No behavioral change.

[max-lt]

Rebased on upstream main (v146.4.0).

The pure-mutex decoupling (de789a7, 5b42bdd) was actually a workaround for a bug in the original Locker: Enter() was called before acquiring the lock. Since V8's entry_stack_ is not thread-safe, this caused a race condition (vector[] index out of bounds crash under parallel usage).

The real fix is the ordering:

• new: Lock -> Enter (hold lock before touching entry_stack_)
• drop: Exit -> Unlock (exit while still holding the lock)

This matches the supabase implementation. IsolateScope removed, Locker handles Enter/Exit with correct ordering, no footgun from DerefMut on a non-entered isolate.