Append em-pthread id to the web worker name.

[kolAflash]

Simplifies picking a web worker when using browser debug tools.

[kolAflash]

Currently all web workers created for threads are called "em-pthread". So when using browser debug tools, you have to try out one web worker after another until you find the one you'd like to debug.

[sbc100]

Can you use a hyphen here?

[sbc100]

It looks like closure does't like this:

building:ERROR: /tmp/emscripten_temp_qawuf4_3/test.jso4.js:356:29: WARNING - [JSC_INEXISTENT_PROPERTY] Property nextWorkerID never defined on PThread
  356| "name":"em-pthread-"+PThread.nextWorkerID};var pthreadMainJs=_scriptName;// We can't use makeModuleReceiveWithVar here since we want to also

[sbc100]

Ah yes, nextWorkerID is debug-only feature.

[kolAflash]

@sbc100

Ah yes, nextWorkerID is debug-only feature.

Thanks for the finding!
Any suggestions how to resolve this?

I'm not well familiar with the Emscripten code base.
Would it be an option to make nextWorkerID available in non-debug mode?

I've pushed a commit where I add a new variable workerId for counting the workers. But I guess that's not the optimal solution.

[sbc100]

I would rather you use the existing nextWorkerID, but only add the -N suffix when ASSERTIONS are enabled.

[kolAflash]

I'd prefer to always have worker thread IDs. Without IDs debugging is just pure pain.

But I've just pushed a commit which puts #if ASSERTIONS around it. And compared to how it was before it's an improvement.

Note:
As far as I understand, this can be enabled by using emscripten with the LDFLAG -s ASSERTIONS=1.

[sbc100]

I'd prefer to always have worker thread IDs. Without IDs debugging is just pure pain.

But I've just pushed a commit which puts #if ASSERTIONS around it. And compared to how it was before it's an improvement.

Note: As far as I understand, this can be enabled by using emscripten with the LDFLAG -s ASSERTIONS=1.

Exactly. Also any build with -O0 (which is also the default) will have assertions enabled. In other words, only release builds won't show these IDs.

Also, just to be clear, you are aware there this is not actually a pthread ID but a worker ID, and a single worker and be re-used to hold different pthreads since they get reused once a pthread exits.

[kolAflash]

[...] Also any build with -O0 (which is also the default) will have assertions enabled. In other words, only release builds won't show these IDs.

Good to know.

Also, just to be clear, you are aware there this is not actually a pthread ID but a worker ID, and a single worker and be re-used to hold different pthreads since they get reused once a pthread exits.

I know the difference, even though I sometimes miss to distinguish between C / C++ thread and web worker.

I didn't know that emscripten reuses a worker when it's assigned thread dies. But debugging short lived threads is anyway always a little harder. And for long living threads the merged solution is very helpful I think.

 

Thanks!