I actually do not have such a scenario, for me its enough to exit and enter once. But I do think that the API is confusing, I would expect the unlocker to handle it and exit completely from the isolate and re-enter to the same state after disposed. I also wonder why I need to explicitly exit/enter the isolate? Is there a case where I would want to create an unlocker without exit the isolate?
On Tuesday 16 January 2024 at 19:30:31 UTC+2 [email protected] wrote: > The isolate can indeed be re-entered and, in that case, a counter is > increased. > The isolate is only exited when the counter becomes zero. > This is indeed a different behaviour from what the documentation > <https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-locker.h;drc=65034fdf545d2f937dd05f1aa535c39ba21ccac5;l=69> > > specifies for the Locker/Unlocker. > > Do you have a scenario where it is not possible or convenient to properly > exit the isolate (using the right number of Exit calls) before using the > Unlocker? > > If thread A has entered the isolate (N times) and then uses the Unlocker > without properly exiting (N times), then it can still use the isolate. > If at the same time thread B uses the Locker and enters the isolate, we > end up with two threads using the isolate simultaneously. > > > On Tuesday, January 16, 2024 at 4:56:51 PM UTC+1 [email protected] wrote: > >> Nikos I am still confuse. >> >> The documentation also state that reenter the isolate is allowed: >> https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-isolate.h;l=731 >> So before creating an unlocker we must exit the isolate the number of >> times we entered it (and then re-enter it again the same number of times >> after the unlocker is destroyed)? >> >> Or is there some mechanism that handles it when we exit/enter the isolate? >> >> On Tuesday 16 January 2024 at 13:58:19 UTC+2 Meir Shpilraien wrote: >> >>> Thanks Nikos, >>> >>> You are right, I missed it in our documentation. Will fix our code. >>> >>> Thank you for the quick response. >>> >>> On Tuesday 16 January 2024 at 13:46:19 UTC+2 [email protected] wrote: >>> >>>> Hi Meir, >>>> >>>> You are correct about the purpose of the CHECK that I introduced in CL >>>> 5173257 <https://chromium-review.googlesource.com/c/v8/v8/+/5173257>. >>>> >>>> The documentation >>>> <https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-locker.h;drc=65034fdf545d2f937dd05f1aa535c39ba21ccac5;l=45> >>>> >>>> of the Locker/Unlocker API specifies that a thread has to exit the isolate >>>> before using v8::Unlocker and enter it again afterwards. >>>> >>>> Without seeing your code, I cannot be sure that this is the issue but >>>> from what you write I suspect that it is. It should also be very easy to >>>> fix. >>>> >>>> See here for a similar fix that had to be made in chromium: CL 5168625 >>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5168625>. >>>> >>>> Best regards, >>>> Nikos. >>>> >>>> On Tuesday, January 16, 2024 at 12:18:22 PM UTC+1 [email protected] >>>> wrote: >>>> >>>> Hey, >>>> >>>> We recently encounter an issue in which our code, when run on V8 main >>>> branch, crashes with this fatal error: >>>> # >>>> # Fatal error in ../../src/execution/isolate.cc, line 4996 >>>> # Check failed: current_thread_id_ == thread_id (<unprintable> vs. >>>> <unprintable>). >>>> # >>>> # >>>> # >>>> >>>> I saw that this check was added recently on this PR: >>>> https://chromium-review.googlesource.com/c/v8/v8/+/5173257 >>>> >>>> Its purpose is to verify a correct use of entering and existing an >>>> isolate. But I do not see it is taking into consideration the >>>> Locker/Unlocker API. In case the current thread uses Unlocker and then >>>> another thread tries to enter the isolate it will failed. >>>> >>>> Is my analysis correct or am I missing something? >>>> Thanks, >>>> Meir >>>> >>>> Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/b91b75b2-95df-4892-9482-5efa16968dben%40googlegroups.com.
