[mythtv] [mythtv-commits] Ticket #1945: DVB-S/diseqc patch
Yeasah Pell
yeasah at schwide.com
Sun Jul 2 17:19:10 UTC 2006
Daniel Kristjansson wrote:
>I have not even attempted to run this code, this is just 3-4
>passes of fixing obvious mistakes with respect to MythTV coding
>standards and conformity with the rest of the code, and adding
>error checking where system libraries are likely to return errors.
>There may have also been some thread safety fixes, but I know
>the code is not really thread safe yet.
>
>One way for you go about this is to start with your patch and
>apply the fixes in the branch to your code one by one. Testing
>along the way. When anything breaks try to fix it or go back
>to the previous version and start applying other fixes. Repeat
>this process until you have something that looks like the code
>in SVN but doesn't have any of the problems the code in SVN has.
>Then just send me a patch with the differences. I'll apply any
>bits that are ok, and either fix other problems another way or
>punt them back to you with an explanation.
>
>-- Daniel
>
I can't easily do what you're suggesting here, because the branch has so
many changes all in one changeset, it would be more difficult to tease
apart the individually coherent changes than it is worth. I'll enumerate
the changes I know about here.
Things I agree with, or at least don't have a major problem with:
1) Changes to the names of many files, classes, types and variables -- I
certainly don't have a problem with that.
2) Changes to the method of adhering to USING_DVB -- I just copied the
method used in dvbchannel, but I thought that was extremely hokey and
I'm glad to see it changed.
3) Movement of the db upgrade code into dbcheck.cpp and the assignment
of a new db schema number -- great, I've been asking for that for as
long as there's been a patch.
4) Movement of some stuff which is technically private from the diseqc
headers to the implementation files -- sure, I agree with that. I don't
much care for interface documentation in the implementation file, but I
understand the desire to reduce the impact of changes on recompliations,
and thus keeping the headers as simple as possible.
5) Random syntax changes, no problem with that.
6) Changing from STL containers to Qt containers -- they are similar
enough that it's not a big deal, and there's plenty of STL in the
application already, so I figured it was ok. But I can understand the
desire to not use two different implementations of the same thing.
7) Adding the new GUI file to the translation qmake file -- great, I
didn't even know about that.
8) Additional db error checking everywhere, which is very good.
9) Changing the default source id on the tune methods to be zero instead
of -1 -- fine, I figured it would be better to use a value that was
entirely out of the range of the database field, but autoincrement won't
ever cough up a zero normally so I suppose it's just as good (and then
it can use a uint for the ID like it should) -- OTOH if somebody ever
makes myth multi-database something like that could be a problem.
10) Locking added to the signal monitor stuff. Great, I wasn't sure
exactly what was required in the signal monitor for thread safety.
11) In general checking if a pointer is NULL before deleting it. I
dislike that, just because it perpetuates the common misconception that
it is unsafe to delete a null pointer, and explicitly refuses to use a
feature of the language that was put there for that exact purpose. But
it's harmless, so I don't really have a problem with it.
Things that I don't really agree with -- I'm not particularly happy with
some of these changes, but I'm not about to argue them either, as it's
not my project:
12) Changing the database identifier lookup functions to use arrays of
QStrings instead of const ascii strings. That one baffles me -- it's
more complex and has more overhead with QStrings, and I don't see any
benefit there -- it's not like i18n'd or unicode db identifiers makes
any sense, and the underlying strings are still stored as const char*
entities in the library's constant data section in either case. Also,
the arrays are now initialized with an explicit size now instead of
allowing the compiler to determine the array count -- there is just no
benefit to that, and it can only cause problems.
13) Generally changing things to favor compactness. I can't say I
generally agree with all of these changes. For example, adding multiple
explicit return statements to a function can be problematic from a
maintenance perspective when done to even moderately complex functions,
as the chance that somebody will decide to add some code to that
function after an earlier conditional return that they didn't spot is
too great, and if that conditional is a rare case such a fault may not
be detected for a long time.
14) Similarly, eliminating interim temporary values is IMO generally a
loss, since the output of any half-assed optimizing compiler will be
indentical in virtually all cases (in fact, breaking subexpressions out
explicitly can help some crappy optimizers in some cases), but you lose
a piece of self-documentation in that the code no longer assigns a
meaningful name to a subexpression -- plus it just adds more work later
if/when the function becomes more complicated and needs to reference the
subexpression multiple times.
15) A comment indicating that the QTime object that is used to determine
the elapsed time since the last tuning request is broken at midnight
because of a wrap -- I don't think this is so. The QTime documentation
only states that the elapsed() method wraps after 24 hours of elapsed
time, which means it would only be a problem if 24 hours had passed
after an initial tune and then a retune was somehow required, which
sounds pretty absurd to me -- and even then, the only negative effect
would be that it would take an extra retune interval of time (since the
counter resets to zero) -- even if this can actually happen at all,
after 24 hours of watching one thing, I doubt waiting an extra retune
interval is going to be a problem.
16) Moving two of the diseqc ioctl methods that previously resided in
the main tree class into static module functions. I definitely don't
agree with that. Currently it is certainly possible to do that, since
those methods didn't currently use any state from the tree object
(actually they did, but you changed it to be passed in), but I can
easily expect that they might use more significant state in the future
as people report that their particular gear needs more tweaks, and one
of the methods had to stay anyway (so now two out of three of a
symmetric set of methods have been randomly moved to static non-class
functions) -- I can't see any good rationale here.
Things that are definitely bugs:
17) Deleting the diseqc tree object in dvbchannel. Not right, needs to
be removed.
18) Changes to the device IDs to use unsigned ints. Ah, I see why some
of the code is broken now. In order to assign unique IDs to nodes that
haven't been created yet, the device tree temporarily assigns nodes with
negative number IDs as placeholders until the final store command, at
which point the nodes are inserted into the database and proper positive
number IDs are assigned for all the new nodes. By changing the IDs to be
unsigned, that totally breaks that. It's true that the original code
couldn't properly represent device IDs greater than ~2 billion, but
changing them all to be unsigned is not a solution to that. Avoiding the
negative number thing would result in a more complex solution (maybe
storing a unique id plus a bool that indicates if it's "real" or not,
and generating strings for the UI to index everything off of based on a
formatted combination of the bool and int), but it would work -- another
much more simple option would simply be to alter the table IDs to match
the range of a signed int.
19) The switch SetChild() method no longer checks the supplied ordinal
to see if it's in the range of the array, but instead tries to retrieve
a child at that ordinal and fails if there is no child object. Of course
this breaks the switch, since it means that you can't add child nodes
unless there are already child nodes present. I imagine this is the
source of the no-switch-children problem I noticed.
... That's about all I have the stamina for so far, which is just what I
can see by manual comparison about halfway through the main diseqc file,
but I hope you can see why I don't have a lot of confidence in the
changeset as a whole right now -- since some of the functional changes
are problematic in a way that indicates a failure to fully understand
the new code, coupled with the fact that it's not straightforward at all
for me to locate the actual functional changes, and it's virtually
impossible to know if I've reviewed them all. I expect there could
easily be more subtle problems that have been introduced that might not
show up in testing.
Regarding thread safety, I think the most important thing is that the
tree be locked for the lifetime of a retrieved rotor object (when the
signal monitor requests the rotor from the channel class and uses it to
update its values), which it currently isn't -- beyond that, the tree
itself could easily be locked when it is in use -- I think that's not
strictly necessary given the current usage patterns (if you have two
dvbchannel objects trying to use the same device at the same time you've
got other problems, and I assume that should never happen), but it would
be a trivial addition so it's probably a good idea whether it's strictly
needed or not -- to avoid failure cascades. As far as I remember, the
other objects are either definitively single-threaded or already locked.
More information about the mythtv-dev
mailing list