Andy Polyakov

> You can do a lot better than build.sh, basically. :) Problem is that there are too many people that would define "do" differently, let alone "better":-) Anyway, the intention...

Please see #196.

> I'm packaging [sigp/lighthouse](https://github.com/sigp/lighthouse) for Gentoo, and blst is one of the last bits I need. I don't quite follow. It's a Rust project and blst is handled transparently by...

> I'm guessing that there are two "steps" in your build: one to compile the C code into a shared/static library, and then the normal Rust build. No. blst instructs...

> Sorry, perhaps I wasn't clear. Since we're trying to be clear. Forget about Rust and Go. > I don't mean to repeat myself too much, but in short: would...

As correctly suggested by @mratsim the threadpool was chosen for having minimum dependencies. Another important reason is that the parallelization pattern is used in both Rust and Go bindings. As...

> > The keyword is that scope.spawn_broadcast never finishes here. In other words the invocations in question are dependent on the progress being made by independent threads. Which is unsustainable...

The examples were obviously exaggerated to illuminate the thesis that scope.spawn_broadcast is considered an inappropriate choice for this library. Because we don't make the assumption that the application makes calls...

Once again, if you don't assume that all calls to this library are made from the same thread, which we don't, then a spawn_broadcast call [made by this library], that...

Have a look at #219.