GNOME Bugzilla – Bug 611911
Set thread names on pipeline threads
Last modified: 2010-04-25 18:41:00 UTC
Some operating systems support assigning names to threads. Giving a name to a thread can be useful for debugging. Under linux this is supported with the prctl(PR_SET_NAME, ...) call. When you call that, you then get a nice thread name in /proc/ and in the output of ps. In gst, for threads created by GstTasks, we could set the thread name based on the GstObject name. For example, we could set the name of a thread started by a pad task to something like GST_DEBUG_PAD_NAME(), i.e. elementname:padname. This could be easily done by modifying GstPad and GstTask, without having to change the elements. For threads started by tasks, but not owned by a pad (see rtspsrc for example), we could modify the elements to explicitly set a name on the task. In the case of rtspsrc, we could call the task GST_OBJECT_NAME(rtspsrc):loop or something like that.
Sounds like something that should be in glib.
We need two things here. A cross platform API to set thread names and to actually set names on pipeline threads. This bug is about naming pipeline threads. As for the low level API to do that, I think we could have something very simple working in gstreamer and then maybe move it to glib.
*** This bug has been marked as a duplicate of bug 580505 ***
Alessandro, where do you need to see the names? We could maybe do something like GST_FUNCPTR_NAME for GstTasks and then use that from gst-debug logging. We could name the threads by the object/pad where they are started.
I don't think we want or need to wait until (a) GLib adds API for that, and (b) we can then rely on a recent-enough GLib. I think it's fine to add something linux-specific locally as a start and then use the GLib API when it gets added if it ever gets added.
Set to NEEDINFO regarding questions in comment #4.
commit f9c74afe62516cad710067de9db2e1a38fb186f4 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Mar 15 14:48:19 2010 +0100 task: configure the object name as thread name When we have prctl available, use it to set the configured object name as the thread name for better debugging. Based on patch by Robert Swain. commit f089c3cceb3e4dee038991e6db4274cb251b4108 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Mar 15 13:48:30 2010 +0100 pad: set a good name on the task of the pad Use the element:pad names to configure a good name for the pad task.
Something else that can be done?
Could you use "if (prctl (PR_SET_NAME, (unsigned long int) thread_name,0,0,0))" instead of "if (prctl (PR_SET_NAME, (unsigned long int) thread_name))" ? bionic/libc doesn't accept prctl without 5 arguments.
(In reply to comment #9) > Could you use "if (prctl (PR_SET_NAME, (unsigned long int) thread_name,0,0,0))" > instead of "if (prctl (PR_SET_NAME, (unsigned long int) thread_name))" ? > bionic/libc doesn't accept prctl without 5 arguments. This was taken care of: commit c78c637a771fef7236bd559a42d18d8b5fc370da Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Mar 15 17:07:59 2010 +0100 task: use bionic/libc friendly arguments to prctl prctl is supposed to take 5 arguments. It used to work with 2 arguments on some versions of libc because it is defined as a varags function there. See #611911 Closing this bug, since we've implemented this now. Lots more can be done, but I don't think we need to keep this bug open for that, and it's probably more productive to file new bugs for specific requests (like showign the thread-name in GST_DEBUG output etc.).