Iirc I had to do a few changes to fix up my PhysX build system to correctly build atomic operations. When building static libraries with threading enabled, make sure you have -s USE_PTHREADS=1 specified at both compile and link time of the library to be as consistent as possible, as well as link time of the final js/html output, since that is in the end what dictates whether atomic ops or dummy no-ops are built.
However looking at this code, I remember that this is due to hitting a fairly exotic issue that is a result of bug https://github.com/kripken/emscripten/issues/3495 . Reading the docs, I notice that I've failed to properly document this scenario, so I wrote down the note https://github.com/kripken/emscripten/issues/3495#issuecomment-140211370 and pushed https://github.com/kripken/emscripten/commit/8e531340fb042e3f0d6e570f3bc5c74b6a471a9a to point this out. Such lock-free loops in main threads are quite rare so this does not occur in many places, but it is still annoying since it's currently undetectable, and more or less requires auditing all places where the main thread might perform lock-free operations, and dropping in a call to the assist function to give worker threads room "to breathe". 2015-09-14 23:24 GMT+03:00 Robert Goulet <[email protected]>: > Alon, Juj, any idea what the problem could be? > > > On Friday, September 11, 2015 at 4:07:51 PM UTC-4, Robert Goulet wrote: >> >> 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 >> <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. > -- 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.
