<div class="gmail_quote">On Thu, Oct 14, 2010 at 3:12 PM, Mike Perkins <span dir="ltr"><<a href="mailto:mikep@randomtraveller.org.uk">mikep@randomtraveller.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">It might be useful if the spawned parts of mythbackend actually had different names so one could figure out what was happening. 32 threads of 'mythbackend' isn't really meaningful, whereas if some of them were, I dunno, 'mythgenpreview' for example, one could see what was what.</div>
</blockquote><div><br></div><div>This is already the case. When we spawn off children, we use fork, which creates a new process, and then we use execl, which changes the name of the process. mythpreviewgen already exists in trunk. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
We already have 'mythtranscode', 'mytharchive',... so why not extend this scheme to forked processes? I understand it might not be so easy with threads, but still...<br></blockquote><div><br></div><div>I think there is some confusion. Forked processes != threads. </div>
<div><br></div><div>If you truly want to know what each of the threads are, fire up gdb, attach to the backend process and get a full backtrace of all threads. This is standard debugging procedure, and is even outlined on the wiki, if I'm not mistaken.</div>
</div>