Support for `context.Context` within all APIs about v8go HOT 4 OPEN

Thanks for the suggestion @kuoruan

I agree that the use of the work Context is conflicting, but I guess that is why we have package scopes in Go.

One of the goals of the project is to keep the API as close to the C++ API as possible; so would be inclined to keep the idea of the v8 Context.

That said, there is a second part to the goals that state: "idiomatic Go"; which context.Context is very much part of; which makes it a conflicting argument 🤔

Once we get closer to a stable API, I'll definitely look at how we can incorporate context.Context; it would definitely be of benefit, especially for some of the callback logic.

from v8go.

+1 on integrating context.Context.

from v8go.

I don't think it makes sense to hide the v8 context, since it has a broader purpose than context.Context.

Also, I think supporting the full context capabilities internally to v8go would effectively mean starting a goroutine in order to be able to handle a cancel event. If that needs to be added on each v8go call that could invoke JS execution, then that could be a lot of starting and stopping of goroutines.

Note that JS execution can happen in a lot more APIs than just running scripts. For instance, even the value casting functions could trigger JS execution. E.g. v8::Value::ToString could call the Symbol.toPrimitive method). It would add a lot of API surface to provide alternative versions of all of these methods to handle a context.

An alternative would be to just support setting and clearing deadline, which could be done using separate methods. This would also be cheaper, since it could just be done using a timer created using time.AfterFunc, which could be stopped or reset when the deadline is cleared or set a following time. If unused, the field could just be left nil. However, unlike TerminateExecution, we would probably want to prevent further JS execution using a boolean flag, in case TerminateExecution gets called outside of the JS code (e.g. between setting the deadline and starting JS execution or between calls that trigger JS execution).

The other thing to note is that forcing JS execution at an arbitrary point in the JS code can leave the V8 context is an unreliable state. For instance, if the JS code sets some global variable and tries to reset it in a finally block, then I think that finally block code could end up being skipped. It may be worth considering whether the feature will be supporting an anti-pattern over starting with a more graceful timeout mechanism and only using a more forceful timeout after a delay. Nothing new is needed for either approach, so anything added would just be making some approach(es) more convenient.

from v8go.

I don't think it makes sense to hide the v8 context, since it has a broader purpose than context.Context.

But v8 context could be combined with context.Context, no? So v8.NewContext maybe should get context.Context as a parameter?

I think supporting the full context capabilities internally to v8go would effectively mean starting a goroutine in order to be able to handle a cancel event.

Only if the context.Context provided is a canceling context. If the caller passes such context.Context to v8.NewContext, then they want this behavior. Now, or they have to implement this outside of v8go, or v8go provides this feature out of the box.

from v8go.