[mythtv-users] Is this normal?

John Goerzen jgoerzen at complete.org
Wed Oct 20 15:29:22 UTC 2004


On Wednesday 20 October 2004 12:58 am, Bruce Markey wrote:
> John Goerzen wrote:
>
> It is true that every one of your assertions was wrong. All
> of your attempts to present evidence that mythfrontend is not
> threaded and the PIDs are each child processes falls flat in
> the face of the fact that it is multi-threaded. 5-6 PIDs are
> the threads within the process and that is normal.

Did you actually read my message?  I did not attempt to present evidence 
that mythfrontend is single-threaded.  I attempted to present evidence 
that there is another possible way to interpret the problem, one that I 
have experienced personally.

While that may be normal, it is also possible that my explanation -- 
leftovers from a dead mythfrontend -- is correct.

> > I'm aware of that,
>
> I actually doubt that you were but nice try. You've failed to
> prove the irrelevant point that a process named "httpd" cannot
> have threads. More importantly, you've failed to prove that it

I never said that a process named httpd cannot have threads.  However, 
citing httpd as an common example of multi-threaded software is just 
wrong.  That's what I was responding to.

> would have any bearing on the fact that "mythfrontend" built
> from the source at www.mythtv.org is threaded and 5-6 threads
> in the process table while it is running is normal.

That is not my problem; I was responding to someone else that said that.

> > Attacking asterisks does not mean that Apache (or any other common
> > httpd) happens to be multithreaded, or that mysql happens to be (I
> > don't know aht the situation is there, but I don't think it is).
>
> spelling error^
>
> I think you had already made it perfectly clear that you have
> no idea how to determine if a process is multi-threaded or not.
> Do you really need to offer further proof at this point?

Please then, show me a multithreaded CERN httpd or Apache 1.x.

> > Or that my mythfrontend doesn't occasionally die.  Really, how
> > could you know that anyway?
>
> You were asserting that your killing of processes was proof
> that the PIDs in the process table were forked children. I can

No I was not.  You are arguing with things that I did not say.

> and do know that mythfrontend is multi-threaded and the PIDs
> in the 2.4.x process table are threads within a threaded process.
> I know that the program, even when you run it, is multi-threaded
> no matter how horribly you've hozed your system.

Fine enough.  I was simply suggesting another possible explanation for 
the problem.  I nowhere asserted that it was not multi-threaded.  I 
nowhere asserted that multi-threaded programs couldn't produce that 
behavior.  I simply provided another possible answer.

> Michael correctly replied "Linux 2.4 shows threads--not processes--in
> top and ps output. Therefore, all 5-6 lines showing mythfrontend are
> actually threads in the same "process" " which is correct, concise
> and informative. Everything in your hostile know-it-all reply was
> confused, utter nonsense and a disservice. It would be nice if
> you could see to it that you apologize to Mike for attacking his
> helpful answer with your misinformation.

There was no disinformation.  He confused the issue in several respects.  
First, multithreaded programs are not the only ones that could cause 
this behavior in the procps utilities.  Have you ever heard of fork() 
and related calls?  Second, the multithreaded nature of mythfrontend is 
not the only possible explanation; as I said, actual experience has 
shown that crashed mythfrontends can leave behind multiple processes 
showing the same symptoms as described.  Finally, he cited other 
"examples" of the same behavior, which included programs that most 
commonly use forking, not threads, for multiprocessing.  While his 
answer that it is normal could be correct, the rest of the post clouded 
things -- and the answer was too simplistic, since it is not always 
normal.

-- John


More information about the mythtv-users mailing list