Multithreading 17/N: Sync performance.now()

[juj]

Synchronize emscripten_get_now() to return values that are comparable across threads. Otherwise each thread would return time compared to the start of each worker hosting a thread, causing extremely subtle bugs in multithreaded task timing code.

One might ask "why don't we spec emscripten_get_now() to count time from 0 from each pthread start" - the reasons for this is are:

• workers are reused to host multiple pthreads. If one pthread quits, the worker is not killed but will stay around. performance.now() returns time counting from 0 from the start of that worker, and not the start of the pthread. Also, workers can be pooled up front with -s PTHREAD_POOL_SIZE=x, and the time from Worker launching to worker having compiled and loaded asm.js/wasm code for execution is nontrivial, so if we wanted to have a model that counted from start of each pthread, we'd still have to compute an offset to account for all of these deltas.
• in other platforms there has not ever existed a wallclock timing function that was not thread coherent (to my knowledge), so a thread incoherent timing function would be a first, and all codebases would likely have to work through this gotcha specifically for the web. We could entertain a emscripten_thread_coherent_get_now() which was a synchronized variant and keep the default one unsynchronized, but that feels like leading a path towards a "best practices" tip "remember that emscripten_get_now() is broken, always use emscripten_thread_coherent_get_now()".

We could perhaps have a -s THREAD_COHERENT_EMSCRIPTEN_GET_NOW=0/1 flag that was default enabled, but for users that know they don't need it, they could disable it for a tiny code size win; but that might be premature for now, so opting to just do this by default in multithreaded builds, and keep it off from singlethreaded build mode.

[kripken]

Instead of delete obj.prop it's better to obj.prop = null (deleting changes the shape of the object, which affects optimization, and then later when you test obj.prop for existence later it changes the shape a second time).

[juj]

Good point about the shape. Though setting obj.prop = null; uses more memory - it still has to carry that null, and this is used only at initial thread startup time, so I don't think there's much optimization in play that could happen?

[kripken]

Yeah, maybe it doesn't matter much. The null by itself though would take just an immediate JS value (same as a float). Anyhow, lgtm either way.