[mythtv] crash in mythbackend

[James Knight]

On Monday, May 12, 2003, at 12:36  PM, Chris Pinkham wrote:

>> Any reason it can't just run in a separate process? From my cursory
>> reading it doesn't *want* to share any data with the main mythbackend
>> process. So, it would seem simpler to spawn a new mythbackend process
>> with a command line of "--flag-commercials <chan> <datetime>" and not
>> have to worry about sharing any state inappropriately. Just say no to
>> threads (when they aren't necessary).
>
> To quote myself off of the irc channel:
>
> 	why work around a bug when you can fix it. :)
>
> Isaac is already working on the fix.

(*Begin philosophical programming style rant*)

I'd like to dispel the notion that it is somehow "less good" or not a 
"real fix" to use a separate process. If I may quote myself (*grin*) 
"Why share memory when you don't need to".

The only difference between a thread and a process is that one shares 
memory and the other doesn't. It is not "working around a bug" to make 
the commercial detection a separate process instead of adding locking. 
That is a quite legitimate, and probably, a simpler fix. If it is a 
separate process, it quite simply NEEDS no locking, and thus is already 
correct.

There is absolutely nothing wrong with having non-shared memory when 
you don't need the shared state. Some of the hardest errors to find/fix 
(and the hardest code to get right in the first place) can be thread 
locking code. Why subject yourself to that if it's not necessary? And 
of course, the other advantage of using a process is that it can crash 
without affecting you.

I'm not ANTI-threads, they are useful for some things, but I think 
people use them too much. Isolation is a good thing -- it increases 
reliability.

(*End philosophical programming style rant*)

But, back to practicality, it's fixed now and still using threads, so 
that's that. :)

James