Hi all, Trying to use the pthread implementation, I stumbled upon this problem described here:
*When -s PTHREAD_POOL_SIZE=<integer> is not specified and pthread_create() is called, the new thread will not actually start to run immediately, but the main JS thread must yield execution back to browser first. This behavior is a result of #1049079 <https://bugzilla.mozilla.org/show_bug.cgi?id=1049079>.* It was easy to fix for our final executable using the PTHREAD_POOL_SIZE option (the engine doesn't get stuck when we start threads), however how is that supposed to work for a static libraries? I ported the PhysX library, and when we initialize it with our engine, it get stuck in this loop : status = pthread_create(&getThread(this)->thread, &attr, PxThreadStart, this); PX_ASSERT(!status); // wait for thread to startup and write out TID // otherwise TID dependent calls like setAffinity will fail. while(atomicCompareExchange(&(getThread(this)->threadStarted), 1, 1) == 0) // <-- stuck here yield(); I specified the PTHREAD_POOL_SIZE when building PhysX libs, but it doesn't seems to work. Is it supported, or a perhaps a bug? On a similar note....... When we start out final executable, we get this message: Preallocating 4 workers for a pthread spawn pool. So far so good, but I also noticed this message in the console exactly when PhysX creates a thread: Preallocating 1 workers for a pthread spawn pool. So it really looks like the static lib isn't using the pool we assigned previously? Are we supposed to see this message more than once? Another point to note, if we use a starting thread pool size of 8, Firefox Nightly stops saying out of memory, while 4 works. That seems rather strange... Any help appreciated! Thanks! -Robert Goulet -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
