multiple goroutines calling worker.Send

[emicklei]

Is this access pattern allowed / supported ? or is the program responsible for synchronzing this (e.g. mutex)?

any ideas how to kill a worker? (from the TODO list)

thank you for creating this package.

[ry]

Ideally sending from multiple goroutines would work, but I haven't tested it. It might need a lock.

Killing a worker could be done with a call to v8::Isolate::TerminateExecution(). Do you need it?

[emicklei]

I will setup such a test (goroutine) as well.

Yes, I need to be able to terminate a worker to protect my program against Javascript errors that result in endless loops or other disasters. My application can load and run arbitrary Javascript code and typically during development of that code, mistakes are made. I would like my application to recover from that without restart.

[ry]

@emicklei I spent a little time trying to get kill working. It doesn't work yet. But maybe you can make more progress with this? https://gist.github.com/ry/1f0656fe15c229c0aa45

[emicklei]

Thank you for working on this request. I will look at it as well.

[emicklei]

not related but probably of interest to you, I created a fork in which I added another builtin function for synchronous message exchange. I realize that this is "against" your original clean design of message passing but I needed it to replace my existing otto based solution. I got this extension working now but it also needs more testing.

[ry]

Why do you need that? I'm not against adding something like that if there's a necessary use case. It's a call from js that send a message to go and returns the response?

[emicklei]

In Javascript, I expose several objects that represent an api written in Go. At the time of its design, most api operations were synchronous and could be mapped to function calls of their Go counterpart. These operations include state access of a large object structure (physics engine).

I have considered changing my api design but that would obviously break all existing programs. So instead, I was looking for a construct that could emulate the behavior using send and recv. With the current implementation, I don't see how I can send a message and wait for the receive to happen and return the value encoded by the message. (even Promises require callback functions).

With this additional request-response feature, I can use these values for transport

type MessageSend struct {
    Receiver  string        `json:"receiver" `
    Method    string        `json:"method" `
    Arguments []interface{} `json:"args" `
}

which can be dispatched on both sides. For example utils.now() is translated to a MessageSend with receiver utils, method now. On the Go side, I have registered a Module value by the name of utils and have a Dispatch(MessageSend) function that performs a function lookup (case) and invocation. A similar mechanism is implemented in Javascript for calling from Go (currently without scoping).

$recv(function(msg) {
    var obj = JSON.parse(msg);
    this[obj.method].apply(this, obj.args)
});

The response of a Go Dispatch(msg) will be an interface{} value encoded in JSON before returning to v8worker and to the caller in Javascript.
Because the flow is now synchronous, when an error happens on the Go side, I can report that to the developers too (using the console Module) complete with stack information (file:line).

There are many other details to this story but this is basically how I intend to use the package.

[emicklei]

( off topic ) fyi, I just published a package implementing this idea. https://godoc.org/github.com/emicklei/v8dispatcher