On Mon, Sep 14, 2020 at 1:46 AM Sam Saffron <sam.saff...@gmail.com> wrote: > > > It is clear that there is no support for OS level forking in v8, this has > been mentioned previously. > > However what is unclear is how to perform rudimentary cleanups so isolates > and contexts can continue to be used post forking. > > In MiniRacer (v8 binding for Ruby) I have a trivial repro of a hang: > > https://github.com/rubyjs/mini_racer/issues/175 > > ``` > (gdb) bt > #0 0x00007f18d4fb202d in pthread_cond_signal@@GLIBC_2.3.2 () from > /usr/lib/libpthread.so.0 > #1 0x00007f18d084a5fc in > v8::platform::DelayedTaskQueue::Append(std::unique_ptr<v8::Task, > std::default_delete<v8::Task> >) () > from /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #2 0x00007f18d0849db0 in > v8::platform::DefaultWorkerThreadsTaskRunner::PostTask(std::unique_ptr<v8::Task, > std::default_delete<v8::Task> >) () from > /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #3 0x00007f18d0848f51 in > v8::platform::DefaultPlatform::CallOnWorkerThread(std::unique_ptr<v8::Task, > std::default_delete<v8::Task> >) () from > /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #4 0x00007f18d1014653 in v8::internal::ConcurrentMarking::ScheduleTasks() () > from /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #5 0x00007f18d09732ab in > v8::internal::MarkCompactCollector::MarkLiveObjects() () > from /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #6 0x00007f18d0972bb1 in > v8::internal::MarkCompactCollector::CollectGarbage() () > from /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #7 0x00007f18d09468ea in v8::internal::Heap::MarkCompact() () from > /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #8 0x00007f18d0943389 in > v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, > v8::GCCallbackFlags) () > from /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #9 0x00007f18d0940f10 in > v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, > v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) () from > /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #10 0x00007f18d094141e in > v8::internal::Heap::CollectAllAvailableGarbage(v8::internal::GarbageCollectionReason) > () > from /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #11 0x00007f18d087cdec in v8::Isolate::LowMemoryNotification() () from > /home/sam/Source/mini_racer/lib/mini_racer_extension.so > #12 0x00007f18d08445f6 in rb_isolate_low_memory_notification > (self=94876640147440) > at ../../../../ext/mini_racer_extension/mini_racer_extension.cc:783 > ``` > > Contexts in mini_racer always get clean isolates, so somehow the task queue > appears to be wedged post fork due to some global state maybe? > > What rudimentary cleanup can we do post for to ensure that new isolates and > contexts can continue to be used? > > isolate->Dispose() seems insufficient. > > We are using v8 8.4
You'll also have to call V8::Dispose() and V8::ShutdownPlatform(), in that order, then call V8::InitializePlatform() and V8::Initialize() again, also in that order. Even then I wouldn't want to bet it actually works, or keeps working going forward. You can go a step further and add a dlclose+dlopen libv8.so in between to force even more cleanup, but again, that's still no guarantee it'll work. A better bet is to prefork before initializing V8. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAHQurc_mRKJCXVsP5EQGBioyzyokxPKKf%2BvDYXh0GRdVPS8v0Q%40mail.gmail.com.
