gopherjs: Make "//gopherjs:blocking" the default

Suppose I have a blocking call on an interface,

var r io.Reader = T{}

n, err = r.Read(b) //gopherjs:blocking

Adding //gopherjs:blocking allows it to work without panic: not supported by GopherJS: non-blocking call to blocking function.

However, marking a func call as blocking does not seem to apply recursively, so if the r.Read happens inside another func which is marked as blocking, I get a panic.

foo := func (r io.Reader, b []byte) (n int, err error) {
    n, err = r.Read(b) // Adding //gopherjs:blocking here fixes it, but what if foo() is inside another library?
    return
}

var r io.Reader = T{}

// I would imagine this could/should mark the r.Read(b) inside foo() as blocking too?
n, err := foo(r, b) //gopherjs:blocking

See complete example here. It works on the normal Go playground here.

Unless there’s a workaround, this is currently preventing me from implementing io.Reader and have it be usable inside standard library (which I cannot modify to add a //gopherjs:blocking comment).

For example,

var r io.Reader = T{}
err := json.NewDecoder(r).Decode(&v) // gopherjs:blocking has no effect here,
                                     // since r.Read() happens inside the
                                     // encoding/json standard package.

Thanks to @dominikh for discussing/explaining/providing sample code. I wanted to make a public issue so that progress can be tracked and people can be referred to here if needed. As always, GopherJS rocks and thanks for making it! This is a testament of how far it got.

About this issue

  • Original URL
  • State: closed
  • Created 10 years ago
  • Comments: 20 (12 by maintainers)

Commits related to this issue

Most upvoted comments

Branch assume-blocking merged into master. //gopherjs:blocking is gone now. 😉

This is an incredible milestone! Congrats!

Just want to point out that all these things are now possible:

If a blocking io.Reader is supported, then it is possible to wrap a websocket connection in a way that implements net.Conn interface. Doing that will allow using net/rpc/jsonrpc package for RPC. It will also allow creating an http.Client with a custom http.Transport that wraps around xhr. All that will allow running more interesting existing Go code (that relies on those low level building blocks) and more possibilities in the frontend.