We do properly set -s USE_PTHREAD=1 on all static lib/executable compile and link time arguments. True for PTHREAD_POOL_SIZE as well. But still, when PhysX creates a thread, we see that message that it is allocating 1 thread, even though we told it to allocate 4 threads. Maybe we need to disregard the message or its a bug. At least it does report allocating 4 threads when the executable gets loaded initially.
As for using that command to empty the proxy calls, I will try that and see if it fixes the deadlock. Thanks for the help! On Monday, September 14, 2015 at 5:43:17 PM UTC-4, jj wrote: > > 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] > <javascript:>>: > >> 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] <javascript:>. >> 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.
