[mythtv-users] Is this normal?

[Michael T. Dean]

Mike Wood wrote:

>>The OP asked if "this [behaviour] was 
>>normal". The answer is: YES it is  n o r m a l.  It is normal because myth is 
>>mulithreaded and a kernel 2.4 shows it like this.  End of story.
>>    
>>
>As the creator of this madness!, I'd like to add something to my
>question.  I failed to say originally that I'm running 2.6.8.1 kernel. 
>So, now, is it still normal??
>
>Sorry to create such kaos....I thought this would be a simple question!!
> ;-)
>  
>
Almost afraid to answer this...  ;)

The answer is, it might be normal...  Short answer:  reboot your system 
and look again (making sure mythfrontend hasn't crashed before you begin 
looking at the top/ps output); if you see several "mythfrontend" lines, 
they are threads, not processes (and this is nothing to worry about).  
If you see only one, your system is probably identifying thread groups 
properly--meaning seeing several /may/ indicate a problem.  (But it 
would most likely be a problem with your system's cleaning up after Myth 
crashes--not a problem with Myth--unless you consider the problem that 
caused Myth to crash the real problem, in which case... I need my lawyer.)

Long answer:

In order for procps programs (which includes ps and top) to be able to 
identify thread groups properly (and, therefore, not report each thread 
separately), the system must be running a thread library with support 
for the CLONE_THREAD flag.  The Native POSIX Thread Library (NPTL), the 
first "stable" version of which was included in glibc 2.3.3--where 2.3.3 
is the current version of glibc--has support for this flag.  Note, also, 
that the system must have a recent version of procps that was compiled 
against *that* thread library.

The NPTL requires an NPTL-compatible version of the Linux kernel (i.e. 
the kernel must have support for Thread-Local Storage (TLS)).  The Linux 
2.6 kernel supports TLS (support for TLS became available somewhere 
around Linux 2.5.28--see http://lwn.net/Articles/5851/ for far more 
technical details than you probably want--but I'm not sure which 2.5 
kernel first shipped with TLS support included).

Therefore, a Linux 2.6 kernel (ignoring the 2.5 development releases) is 
required to build NPTL, and NPTL was first released as "stable" with the 
current version of glibc, 2.3.3, on August 3, 2004 (just 2 1/2 months 
ago).  Since glibc is the foundation on which the software of your 
GNU/Linux system is built, it is generally only installed once during 
the initial compile of the OS (i.e. it's *always* better to start over 
from scratch than to try to upgrade glibc on a working system--yes, I'm 
ignoring package managers--which can make it easy to upgrade large 
portions of the system all at once--here because the distro builder can 
start from scratch while masking that fact for you...).  Therefore, it's 
possible your system was created using a version of glibc without NPTL 
support or that your procps was compiled against glibc with linuxthreads 
(the thread library being replaced by NPTL) and then your glibc was 
recompiled with NPTL support.

As a matter of fact, building a Linux 2.6 system is very tricky at this 
point.  Because the kernel developers have finally told the masses of 
developers to stop writing their software to use the Linux kernel 
headers directly (which causes problems when developers use 
functionality that is not part of the kernel's public binary interface), 
the "stable" released versions of many software packages that are 
required/assumed to be part of a working GNU/Linux system do not compile 
properly against the "scrubbed" headers (from which all non-public 
interfaces have been removed).  Therefore, many "Linux 2.6" systems are 
actually systems that were built from Linux 2.4, on top of which a Linux 
2.6 kernel was added.  In some cases, vendors will then recompile glibc 
and enable the NPTL, after which they recompile some/most/all of the 
packages on the system.  This process tends to carry over a lot of 
baggage--possibly even programs that do not take advantage of features 
of your kernel or glibc.  Within the last couple of months, it has just 
started to become possible to create a true Linux 2.6 system (i.e. 
without having used Linux 2.4) that can be considered relatively 
stable--however, it still requires a lot of CVS/alpha/beta code and many 
patches to get everything working.

Note, however, that it is possible to get NPTL support on a system with 
Linux 2.4.  Red Hat, the primary developer of the NPTL, needed support 
for NPTL in the kernels being used by their commercial customers before 
it became available in the "vanilla" kernel releases and wanted to 
continue to support customers that chose not to upgrade to Linux 2.6 
immediately.  Therefore, they backported TLS to the Linux 2.4 kernel.  
Unfortunately, the patches are an ugly mess (no offense, Red Hat) so 
unless you have a mission critical requirement for Linux 2.4, you're 
probably better off with Linux 2.6 if you want/need NPTL.

It's also possible to get NPTL on a system without glibc 2.3.3.  NPTL 
has been available as a separate ("not officially recognized as stable") 
add on for glibc since 2.3.

Therefore, the vendor of your distribution had to make a plethora of 
decisions about the configuration of the operating system you're using.  
Depending on how they weighted their decisions, they may have included 
some of these advanced features, may have left some out; or may have 
added some, but--either due to time/budget constraints or due to 
technical problems (like the Linux 2.4 baggage)--may not have taken full 
advantage of the features they added.  And, more than likely, they 
didn't document the extent to which support for these features is 
incorporated into the distro--not to mention the process they used to 
incorporate the features in the operating system.  (And here we all 
thought we were in complete control of our system configurations...  In 
the real world, sometimes it's better to have the ability to have 
complete control but defer (or "delegate") a portion of that control to 
someone else for efficiency's sake. :)

Basically, right now is a very bad time to ask this question.  In a 
couple of years--once TLS/NPTL become more pervasive--it will be much 
easier to say whether you should see multiple lines of "mythfrontend" in 
your top/ps output. without all the qualifications above.  :)

Hope I didn't over-simplify my answer, this time.  ;)

Mike