[mythtv-users] Is this normal?

[Bruce Markey]

John Goerzen wrote:
> On Tue, Oct 19, 2004 at 03:13:12PM -0700, Bruce Markey wrote:
> 
>>I always get a chuckle out of this type of reply. Michael's
>>message was accurate as usual. The same can not be said of
>>anything in your reply other than perhaps you didn't make
>>any spelling errors.
> 
> 
> That's not true at all (well, maybe the spelling part, but I haven't
> checked <g>)

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.

>>John Goerzen wrote:
>>
>>>On Monday 18 October 2004 11:37 pm, Michael T. Dean wrote:
>>>
>>>No, you're confusing the issue.  A distinct PID is a distinct PID, no 
>>>matter what.
>>
>>And each thread has a distinct PID Linux 2.4 or earlier no
>>matter what.
> 
> 
> OK, and the point is...?

The point is that he did not confuse the issue and gave a clear
and accurate answer. You were dead wrong.

>>servers daemons use the process name "httpd". There have been
>>multi-threaded web servers dating back to 1994.
> 
> 
> 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
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.

>>>It is *not* what you have described; these 
>>>are separate processes.

[I wonder if he will again try to say that this is correct?]

>>They are threads within the mythfrontend process. As always,
>>putting asterisks around a word does not make the statement
>>correct. More often, it indicates the author can not be sure
>>of something they are trying to impose and emphasis would
>>make it seen as if it should not be questioned.
> 
> 
> 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? 

> 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
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.

> Everything I said was correct.

[He did!]

No, it was not. Haven't you embarrassed yourself enough?

  It is possible that he had a
> mythfrontend crash.  It is possible that he didn't, too.  The original
> reply didn't even contemplate that possibility,

Nor should anyone as that has nothing to do with the question or
answer. The OP's question was "I see 5-6 instances of mythfrontend
in Top. Only one of them is using significant CPU, but they are all
using the same amount of memory.  Is this normal?" Yes it is. The
instances are the threads within mythfrontend and the busy thread
is the video output loop. If there was more than one process for
mythfrontend running, which is possible, the process sizes would
almost surely be different and there would be N times as many
threads.

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.

--  bjm