platform: pump_message_loop, run_idle_tasks, GLOBAL_PLATFORM

[inteon]

Added pump_message_loop and run_idle_tasks to v8::Platform.
The GLOBAL_PLATFORM now manages the active platform.

[bartlomieju]

@inteon very nice! The code looks mostly good to me, however a segfault happens in test_single_threaded_default_platform test. It's an already existing test so my hunch is that some default values have changed in this PR.

[bnoordhuis]

Thanks for the pull request, @inteon.

I like the general thrust but I have mixed feelings about bypassing V8's public API and using the internal DefaultPlatform directly.

I assume you're doing that so you can use placement new but is that really necessary? Is the current UniquePtr<Platform> approach not workable?

[inteon]

@bnoordhuis @piscisaureus @bartlomieju The main challenge I encountered implementing this PR, is the pump_message_loop function that needs a pointer to platform as a function argument. This means that unique ownership (like UniquePtr<Platform>) cannot be used, because the call to initialize_platform would transfer ownership, and the platform pointer is still needed for the pump_message_loop call.

For that reason, I'm using Pin<Arc<Platform>>. This however means that I have to allocate the heap space in rust and do a v8 in-place construction of the Platform object. This also means that the logic for the number of threads in the thread pool is skipped. Therefore this logic has to be implemented in rust (if thread_pool_size = 0 for call to new_default_platform instead the number of cpu cores - 1 should be used as the thread_pool_size; this is the logic from v8).

@piscisaureus I think the reference counter for the Arc increases when calling get_current_platform or when cloning the Arc. I could be wrong, but I think that the reference count will exceed 1, right?

[bnoordhuis]

@inteon Would SharedPtr work? They're immutable shared references but I'd say it's okay to bend the rules a little behind the scenes and convert to a mutable pointer at the Rust/C++ edge.

[inteon]

@inteon Would SharedPtr work? They're immutable shared references but I'd say it's okay to bend the rules a little behind the scenes and convert to a mutable pointer at the Rust/C++ edge.

For a SharedPtr to work, I think you have to implement the Shared trait, and that requires a shared pointer to be kept on the cpp side. I previously started implementing that solution, but I thought it wouldn't be a simpler/ more elegant solution.

I'll retry that solution, because ofc this solution also adds a lot of challenges.

[inteon]

@inteon Would SharedPtr work? They're immutable shared references but I'd say it's okay to bend the rules a little behind the scenes and convert to a mutable pointer at the Rust/C++ edge.

Just finished creating a solution based on SharedPtr 🥳 . It requires a bit more code, but requires less hacks.

[bartlomieju]

@inteon nice work! This looks much better to me. I'll defer to review from @bnoordhuis and @piscisaureus

[piscisaureus]

LGTM
That said, I'm still a bit nervous about it - @bnoordhuis can I get your sign off as well?

[bnoordhuis]

LGTM, thanks @inteon. Ideally, the test wouldn't use natives syntax (not stable across V8 releases) but if this is the only reliable way to test then so be it.