-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add multithreaded version of Jolt to the package #134
Comments
Regarding an example with callbacks, that is now very challenging again. The latest Emscripten now no longer puts code in the This is back in the situation where multi-threading is essentially non-functional for all but trivial cases. The minimal requirements I can think of before it is viable for anything using a JS callback:
It may be possible to hijack the PThread singleton in the module and use the An alternative would be subclassing the ThreadPool and somehow accessing the thread-workers and giving them EM_ASM hooks to call a JS world 'on-thread-create' callback, which then calls 'thread.start' after it has setup, but that is even more non-trivial. new NPM package
|
I really wish there was an official method to do this, since anything unofficial is risky and could break at some point in the future, which is one of my main concerns about multithreading in an official package. With current emscripten, this is an example // START: MULTI THREADED
if(ENVIRONMENT_IS_PTHREAD) {
const _invokeEntryPoint = invokeEntryPoint;
invokeEntryPoint = (ptr, arg) => {
if(arg.script) {
import(arg.script).then(module => {
module.default(Module, arg.params).then(() => _invokeEntryPoint(ptr, arg.value));
})
} else {
_invokeEntryPoint(ptr, arg.value);
}
}
} else {
const _spawnThread = spawnThread;
spawnThread = (threadParams) => {
threadParams.arg = { value: threadParams.arg, script: Module['workerScript'], params: Module['workerScriptParams']};
_spawnThread(threadParams);
}
}
// END: MULTI THREADED usage: const contactListener = new Jolt.ContactListenerJS();
Jolt['workerScript'] = './on-worker-conveyor-belt.js';
const workerParams = Jolt['workerScriptParams'] = {
contactListenerPtr: Jolt.getPointer(contactListener),
angularBelt: new Uint32Array(new SharedArrayBuffer(4)),
linearBelts: new Uint32Array(new SharedArrayBuffer(20))
}
// workerParams are sent to all workers at this point, and then never again until Thread restarted
// so no more modifying the workerParam entries outside of internal SharedArrayBuffer values
initExample(Jolt, null);
// conveyor demo
workerParams.angularBelt[0] = angularBelt.GetID().GetIndexAndSequenceNumber();
workerParams.linearBelts.set(linearBelts.map(belt => belt.GetID().GetIndexAndSequenceNumber()));
// ensure all SharedArrayBuffer are set prior to the next execution of a PhysicsEngine Step Sample module: const onWorker = async (Jolt, args) => {
// values passed during JoltInterface initialization, when the ThreadPool is started
const { contactListenerPtr, linearBelts, angularBelt } = args;
// linearBelts and angularBelt are ui32 arrays of a fixed size, but who's values may be changed on any thread
const contactListener = Jolt.wrapPointer(contactListenerPtr, Jolt.ContactListenerJS);
contactListener.OnContactAdded = (body1, body2, manifold, settings) => { ... }
}
export default onWorker; |
Hello, I'm currently on holiday so can't try anything out until I'm back. Wrt cmake: you usually build different settings to different locations so something like:
Where $MT indicates if it a multi threading build or not. |
This does trigger two downloads since it is making two build folders, and I don't think by default CMake will support caching the git repo anywhere, but there is probably not much overhead in cloning down the original library twice. This is a PoC of the above workerScript + workerParam idea: PhoenixIllusion@ce18a68 |
Yes, that should not be a problem, if you switch between debug/release using |
I've finally looked at the change, to me the solution looks quite reasonable. The main issue is that you're building 2x to Build/$BUILD_TYPE and cmake afaik doesn't pick up changes to |
See #110
We can build Jolt in multithreaded mode now, we should create an example (a plain one and one implementing callbacks) and make the build available in the package.
The text was updated successfully, but these errors were encountered: