The -s PTHREAD_POOL_SIZE option is a linker option that can be used only when linking to the final .js/.html file. If specified in other stages (compiling, linking a static library), it is ignored. If you are specifying -s PTHREAD_POOL_SIZE=4 to final .js link, and still are seeing a message that it is pooling up only one thread at .js startup time, then it is a clear bug. Although I am not sure I understand, since you first mention that "we see that message that it is allocating 1 thread", but in the later sentence "At least it does report allocating 4 threads when the executable gets loaded initially"?
2015-09-15 16:12 GMT+03:00 Robert Goulet <[email protected]>: > 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]>: >> >>> 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. > -- 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.
