1369222 - Allow deregistration of threads whose lifetimes we do not control

Status: RESOLVED DUPLICATE of bug 1773286

(Core :: Gecko Profiler, enhancement)

Description

[(No longer employed by Mozilla) Aaron Klotz]

I have a bit of a unique situation: I need to profile some threads that are launched by the OS as part of the system thread pool. Registering those threads is easy enough; I just lazily call profiler_register_thread the first time our code sees an unregistered thread pool thread.

Unfortunately, the system is controlling the lifetime of the threads in its pool and there is no mechanism for a finishing thread to call back into our code before it terminates.

Can we add a profiler_unregister_thread(tid) call, or some other mechanism so that we can unregister a thread other than the calling thread?

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

Markus, thoughts?

Comment 2

[Markus Stange [:mstange]]

(In reply to Aaron Klotz [:aklotz] (a11y work receiving priority right now, please send interceptor reviews to dmajor or handyman) from comment #0)
> Can we add a profiler_unregister_thread(tid) call, or some other mechanism
> so that we can unregister a thread other than the calling thread?

Sure, that seems reasonable. When and where would you call it? I think you still have to call it before the thread actually disappears, otherwise we'll attempt to sample a non-existent thread and I don't know how well that would go over.

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Markus Stange [:mstange] from comment #2)
> Sure, that seems reasonable. When and where would you call it? I think you
> still have to call it before the thread actually disappears, otherwise we'll
> attempt to sample a non-existent thread and I don't know how well that would
> go over.

That's a good point... Unfortunately, the best that I can probably do is wait on the pool thread's handle which wouldn't be signalled until the thread was already gone, which brings us right back to the original problem. :(

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

Though from what I see of the profiler sampling code, the sampler would safely recover on Windows and Mac. It looks like the linux/android sampler would need to be changed to fail gracefully from tgkill(2).

Comment 5

[Markus Stange [:mstange]]

(In reply to Aaron Klotz [:aklotz] (a11y work receiving priority right now, please send interceptor reviews to dmajor or handyman) from comment #4)
> Though from what I see of the profiler sampling code, the sampler would
> safely recover on Windows and Mac. It looks like the linux/android sampler
> would need to be changed to fail gracefully from tgkill(2).

That doesn't seem too bad then. Maybe we could even unregister a thread automatically if the sampler detects that it has gone away? We'd only do that for threads that are explicitly marked as "not under our control".

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Markus Stange [:mstange] from comment #5)
> That doesn't seem too bad then. Maybe we could even unregister a thread
> automatically if the sampler detects that it has gone away? We'd only do
> that for threads that are explicitly marked as "not under our control".

That thought crossed my mind as well. I think that might make for a cleaner API with no potential for footguns.

I'll try to throw together a patch.

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=210c788f4f38980de18c3a38d16ffc89e37ead36

Comment 8

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Coincidentally (as I'm reviewing unprioritized bugs), bug 1773286 was just filed with the same request.
Since this bug here is 5 years old, and thread registration has changed a bit since then, I'll mark it as duplicate. I'll mention Aaron's prototype there.